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System  (FLTOPS).  Since  the  study  objective  was  to  produce  a detailed 
design  for  FLTOPS,  this  document  takes  the  form  of  a rigorous  speci- 
fication. Appendix  A contains  a report  on  the  validation  of  this 
specification.  Appendix  B contains  additional  information  regarding 
changes/modifications  incurred  during  the  extended  test  phase  of  the 
contract.  Appendix  C contains  listings  of  a test  case  and  results  of 
the  test  case. 
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1.0  INTRODUCTION 


1.1  CURRENT  MODUS  OPERANDI  FOR  PREPARING  FLIGHT  TEST  ANALYSIS  SOFTWARE 

Each  flight  test  project  is  both  similar  to  and  different  from 
every  other  project  that  has  been  done.  The  similarities  have  resulted 
in  the  development  of  several  general  and  integrated  collections  of  com- 
puter codes  to  assist  in  analyzing  the  flight  test  data.  Examples  are 
AFTDS/DAPS,  SANDS,  UFTAS  and  GSAP.  The  development  and  maintenance  of  such 
generalized  programs  requires  a community  of  professional  programmers,  soft- 
ware analysts,  and  computer  scientists.  The  applications  users  for  these 
codes  are  another  community  of  flight  test  engineers  and  analysts  whose 
expertise  lies  in  the  areas  of  aircraft  performance  and/or  aircraft  system 
or  subsystem  development. 

The  analyses  associated  with  each  new  project  would  be  exceedingly 
exoensive  if  it  were  not  for  the  existence  and  evolution  of  general  software 
that  is  possible  only  because  of  the  similarities  among  projects. 

The  differences  that  exist  among  analysis  projects  are,  however, 
still  great  enough  t-’  require  the  allocation  of  several  man-months  to  several 
man-years  of  effort  to  accotmiodate.  The  general  codes  must  be  assembled 
in  unique  sequences,  the  aircraft,  atmospheric,  geopotential,  and  kinematic 
parameters  must  be  specified,  engine  and  drag  models  must  be  coded  for 
each  new  aircraft,  etc.  The  accomplishment  of  this  customization  process 
requires  both  aircraft  and  software  specialists  working  in  a cooperative 
and  sometimes  an  intricately  dependent  fashion. 

Some  of  the  problems  that  arise  in  this  environment  are  the  motiva- 
tion for  the  FLTOPS  concept.  For  example,  the  specification  of  some  analysis 
options  or  particular  models  must  now  be  done  several  different  times.  This 
redundancy  is  a waste  of  effort  and  can  lead  to  inconsistencies  and/or 
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errors  that  are  difficult  to  detect.  There  exist  so  many  details  to  specify 
that  supervisory  personnel  cannot  easily  review  the  analysis  techniques 
that  have  been  Implemented  by  the  engineer/program  analyst  team.  Of  course, 
various  levels  of  experience  exist  In  both  the  software  and  engineering 
specialties.  The  current  methods  of  documenting  previous  software  configura- 
tions are  Inadequate;  previous  solutions  and  Important  Insights  are  apparently  | 

too  often  stored  only  In  Individuals*  memories. 

The  redundancy  of  effort,  the  tedious  and  meticulous  activities 
required  to  find  and  make  simple  software  changes,  the  Inadequate  documen- 
tation of  the  procedures  used,  and  communications  difficulties  between 
the  engineer  and  the  software  specialists  are  current  characteristics 
of  the  AFFTC  work  environment  that  might  be  improved  by  proper  exploita- 
tion of  some  additional  software  technology.  This  realization  by  AFFTC 
analysts  led  to  the  development  of  the  Flight  Test  Oriented  Precompiler 
System  concept. 

1.2  OBJECTIVES  OF  THE  FLIGHT  TEST  ORIENTED  PRECOMPILER  SYSTEM  (FLTOPS) 

1.2.1  Reduce  the  Effort  and  Span  Time  for  Configuring  Project-Specific 

Software 

The  fundamental  objective  of  the  FLTOPS  design  and  development  1s 
to  effect  a substantial  reduction  In  the  labor  effort  and  the  time  span 
now  required  to  assemble  and  customize  existing  data  reduction  programs. 

Each  flight  test  project  requires  data  reduction  programs  that  are  uniquely 
linked  together  and/or  modified  for  the  objectives  and  activities  of  that 
project  and  the  characteristics  of  the  aircraft.  A high  degree  of  standard- 
ization has  been  achieved  by  building  programs  that  are  quite  generic  and 
by  providing  special  programs  to  construct  project-specific  data  files 
and  program  sequence  specifications.  Complete  standardization  of  flight 
test  data  reduction  software  Is  not  possible;  there  will  always  be  a need 
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for  new  code  that  has  not  existed  previously  and  a need  to  use  only  a 
subset  or  a simplified  version  of  the  existing  standardized  code.  These 
adaptations  of  the  standard  programs  currently  take  man-months  to  man-years 
of  labor  to  produce.  Both  flight  test  engineers  and  mathematician/program 
analysts  are  involved  in  this  activity. 

A review  of  the  types  of  human  activity  involved  in  creating  project- 
specific  software  from  generic  library  routines  suggests  that  major  elements 
of  the  work  are  suitable  for  automation.  It  is  possible,  for  example, 
to  anticipate  places  within  existing  code  where  modifications  are  likely 
to  occur.  It  is  also  possible  to  determine  several  completely  definable 
options  that  might  be  selected  and  to  specify  a single  option  using  a few 
key  words  or  phrases.  Thus,  repeated  reimplementations  of  similar  logic 
or  remodifications  that  are  structurally  equivalent  need  not  be  the  burden 
of  human  analysts.  Similarly,  unnecessary  repetitions  of  model  or  tech- 
nique options  can  be  eliminated  as  a human  task.  Many  other  examples  can 
be  cited,  all  of  which  suggest  that  the  tasks  associated  with  configuring 
project-specific  flight  test  data  reduction  software  can  be  made  much  less 
labor-intensive.  A fundamental  objective  of  FLTOPS  is  to  provide  computer 
capabilities  that  reduce  unnecessary  human  labor  and,  thus,  reduce  the  time 
and  costs  required  to  support  flight  testing. 


1.2.2  Provide  a Tool  for  Customizing  Software  According  to  Project- 

Specific  Requirements 

Although  the  major  goal  of  FLTOPS  is  to  reduce  the  labor  necessary 
to  configure  software  that  will  be  adequate  to  support  the  analysis  of  the 
flight  test  data,  it  is  expected  that  the  software  generated  by  the  FLTOPS 
will  use  computer  resources  efficiently.  General  codes  that  contain  logic 
that  is  unneeded  in  particular  analyses  need  to  be  trimmed.  Storage 
specifications  that  are  super-sufficient  should  be  reduced  to  be  adequate, 
but  not  wasteful.  Parameters  that  are  normally  computed  but  become  constants 
in  particular  cases  should  be  replaced  by  their  numeric  values,  etc. 


1-3 


The  effort  required  by  software  maintainers  to  accomplish  these 
types  of  customizing  functions  is  quite  routine,  requires  great  attention 
to  detail,  is  difficult  to  accomplish  with  complete  thoroughness,  and  may 
not  be  worth  the  time  required.  If,  however,  the  FLTOPS  can  accomplish 
these  functions,  the  benefits  could  be  substantial.  The  nature  of  the 
customizing  task  is  generally  quite  compatible  with  precompile-time 
automated  capabilities.  Therefore,  an  objective  of  the  FLTOPS  is  to  provide 
a means  for  modifying  software  so  that  analyses  can  be  done  with  efficient 
use  of  computer  resources.  The  accomplishment  of  this  objective  will, 
of  course,  imply  the  ability  to  do  more  analyses  with  the  computer  re- 
sources that  are  available. 


1.2.3  Increase  the  Visibility  and  Comprehension  of  Analysis  Techniques 

Being  Employed 

Before  standa-^dized  computer  programs  were  available,  flight  test 
engineers  presumably  needed  to  derive  the  mathematical  formulae  associated 
with  each  flight  test  project.  These  formulae  served  as  the  basis  for 
the  development  of  specific  computer  programs  for  the  project.  As  libraries 
of  programs  developed  and  standardization  increased,  the  need  for  the 
engineers  to  understand  the  details  of  the  logic  within  already-developed 
programs  declined.  At  the  current  time,  it  is  possible  to  configure 
combinations  of  routines  that  may  execute  properly,  but  may  not  do  precisely 
what  the  engineer  thinks  they  do.  Experienced  analysts  can  detect  misuses 
of  existing  software  if  they  have  good  visibility  of  the  program  archi- 
tecture. One  of  the  needs  that  FLTOPS  can  fill  is  the  need  to  make  visible 
the  choices  a flight  test  engineer  has  made.  The  insights  and  experience 
of  colleagues  and  supervisory  personnel  can  then  be  applied  to  assure  the 
integrity  and  appropriateness  of  the  analysis  that  has  been  specified. 
Therefore,  an  objective  of  the  FLTOPS  system  is  to  provide  feedback  to 
the  analysis  designers  about  the  nature  of  the  analysis  procedures  (in 
the  form  of  software)  that  they  have  chosen.  This  objective  can  be  thought 
of  as  a quality  assurance  objective. 


1.2.4  Provide  Archival  Documentation  and  Easy  Reconstitution  of  Past 
Methods/Models 


A not-uncommon  experience  among  flight  test  engineers  and  program 
analysts  is  the  need  to  remember  how  a particular  special  requirement 
was  handled  1n  a past  project.  Or  similarly,  in  reactivating  software 
used  In  the  p?st,  the  analyst  needs  to  recall  the  reason  that  a certain 
software  peculiarity  appears.  Perhaps  the  actual  software  may  need  to 
be  retrieved  and  modified  further  for  a new  test  project.  Time  and  effort 
may  be  wasted  unnecessarily  because  archival  documentation  Is  Inadequate. 
This  documentation  requirement  may  be  satisfied  If  the  previous  objective 
Is  satisfied  (Section  1.2.3).  Yet  there  are  differences  In  purpose  which 
may  dictate  different  design  properties.  Thus,  It  should  be  stated 
explicitly  that  support  of  proper  archival  documentation  of  flight  test 
analysis  software  Is  an  objective  of  the  FLTOPS  development. 


1.2.5  Provide  a Tool  Which  Can  be  Maintained  and  Upgraded  Easily 

Another  objective  of  the  FLTOPS  Is  the  development  of  software 
that  conforms  to  design  principles  that  are  consistent  with  existing 
applications  software  at  AFFTC.  FLTOPS  software  should,  therefore,  be 
as  general  as  practical  and  have  characteristics  that  desensitize  it  to 
a changing  environment  (e.g.,  new  computing  hardware,  new  functional 
requirements,  etc.).  The  objectives  described  below  are  really  summarized 
by  saying  that  FLTOPS  must  satisfy  certain  design  and  Implementation 
constraints , 

rt  is  necessary  that  the  FLTOPS  software  be  usable  at  Edwards  AiB, 
but  also  at  otner  computing  establishments  that  use  different  operating 
systems,  hardware,  and  language  translators.  To  the  maximum  degree 
possible,  the  capabilities  of  the  FLTOPS  software  should  he  provided 
with  features  that  are  common  to  all  or  most  large  computing  environments. 
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Because  FLTOPS  software  will  provide  some  rather  sophisticated  capabilities, 
the  portability  objective  will  have  to  be  emphasized  in  both  the  design 
and  implementation  efforts. 


The  capabilities  foreseen  for  FLTOPS  are  not  necessarily  unique  to 
flight  test  data  reduction  applications.  It  Is  desirable  to  avoid  Imbedding 
Into  the  design  or  Implementation  of  FLTOPS  any  characteristics  of  flight 
test  data  reduction  that  would  limit  the  utility  of  FLTOPS  In  other  ap- 
plication settings.  The  degree  to  which  this  objective  can  be  met  Is  not 
completely  clear  at  the  outset.  Yet,  It  Is  clear  that  application-indepen- 
dence Is  a proper  objective  unless  Its  achievement  represents  a large 
incremental  development  cost. 

It  Is  anticipated  that  the  utility  of  the  FLTOPS  will  Increase 
as  normal  maintenance  of  existing  software  and  the  development  of  new 
standard  software  occurs.  An  objective  of  the  FLTOPS  development  Is  to 
provide  for  evolutionary  Improvements  and  to  avoid  the  need  for  costly 
redevelopments  in  which  the  bulk  of  the  software  Is  discarded  and  rewritten. 
This  objective  has  Implications  about  where  capabilities  are  provided 
for  In  the  original  design.  Its  satisfaction  has  Important  cost  Implica- 
tions to  the  Air  Force. 
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2.0  OVERVIEW  OF  THE  FLTOPS  SYSTEM 
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The  FLTOPS  system  was  designed  to  fulfill  a need.  This  need,  although 
variously  expressed  by  the  individuals  involved,  is  quite  simply  to  get  the 
job  done  more  efficiently.  The  Job,  although  encompassing  many  aspects  as 
alluded  to  in  Section  1,  has  as  its  focal  point  the  capability  to  customize 
existing  FORTRAN  code  to  meet  the  specific  requirements  associated  with 
current  projects.  This  customization  process  should  be  fast,  flexible, 
easy  to  use,  and  most  importantly,  capable  to  responding  to  the  changing 
needs  of  a demanding  environment. 

The  FLTOPS  system  design  fulfills  this  need.  At  the  center  of  the 
FLTOPS  system  is  a new,  high-level  p»-ogramming  language  similar  in  form 
and  design  philosophy  to  many  other  modern  languages  such  as  PL/1  and 
ALGOL.  Programs  written  in  this  new  language  can  read  inputs,  manipulate 
data  values  and  produce  output  as  do  other  high-level  languages.  The 
unique  quality  of  the  language,  however,  is  that  its  primary  purpose  is 
to  generate  highly  specific  FORTRAN  code  based  upon  user  requests. 

The  FLTOPS  system  accomplishes  this  task  by  providing  users  with 
a system  which  accepts  FORTRAN  code  along  with  special  instructions  in- 
dicating how  to  select,  modify,  and/or  create  new  code.  The  FORTRAN  and 
special  instructions  reside  intermixed  in  what  is  known  as  an  FCF  for 
FLTOPS  Configuration  File.  The  FCF  can  be  thought  of  as  a special  program 
vihose  function  it  is  to  generate  FORTRAN  source  code  suitable  for  input 
to  a compiler.  This  program  can  have  its  functions  and,  thvarefore,  its 
output  controlled  by  reading  data  ft'om  an  input  file.  Although  the  primary 
output  is  FORTRAN  source  code,  messages  and  data  can  also  be  output  by 
the  system. 

This  system  is  under  control  of  a master  program  called  the  FLTOPS 
precompi ler.  The  precompiler  actually  processes  the  FCF,  or  program,  and 
performs  the  necessary  functions  of  reading  in  data  and  outputing  source 
code  as  instructed  by  the  program  requirements.  A simple  and  analogous 
way  of  conceptualizing  the  precompiler  is  to  think  of  it  as  a comouting 
machine.  Just  as  a computer  executes  the  functions  of  a computer  p»'ogram. 
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the  precompiler  executes  the  functions  indicated  in  the  FCF.  This  psuedo- 
machine  concept  is  schematically  represented  in  Figure  1. 

The  FLTOPS  system,  thus,  contains  four  distinct  components.  A 
computer  program  written  in  a mixture  of  FORTRAN  and  a special  high-level 
language  is  commonly  referred  to  as  the  FLTOPS  Configuration  File,  or 
simply,  FCF.  This  program,  in  turn,  can  read  data  from  an  input  file.  This 
data  can  be  used  by  the  FCF  to  directly  or  indirectly  control  output  genera- 
tion. The  output  is,  in  general,  customized  FORTRAN  source  code  that  is 
specifically  designed  by  the  user  to  meet  his  requirements.  This  total 
task  is  effectively  accomplished  by  executing  the  FCF  program  on  a pseudo- 
machine known  as  the  precompiler. 

In  any  computer  system  the  program  simply  indicates  in  which  order 
and  in  what  quantities  the  basic  machine  operations  should  be  carried  out. 
The  FLTOPS  system  works  the  same  way.  The  precompiler  performs  all  the 
functions  of  reading  and  writing  and  processing  as  directed  by  the  FCF 
progVam.  From  a user's  point  of  view,  however,  it  is  quite  natural  to 
refer  to  the  program  as  "reading"  inputs  or  "writing"  outputs.  In  Figure  1, 
the  FCF  is  shown  as  receiving  and  generating  outputs  even  though  technically 
the  work  is  being  accomplished  by  the  precompiler. 

A discussion  of  the  FCF  structure,  the  inputs  it  reads,  and  the 
outputs  it  generates  follows.  Because  of  its  technical  nature,  a discussion 
of  the  precompiler  design  is  postponed  until  Section  6. 
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THE  MACHINE 


Figure  1.  Basic  Relationships  '^monq  FLTOPS  System  Components 
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2.1  THE  FLTOPS  CONFIGURATION  FILE 


The  FCF  is  a combination  of  FORTRAN  language  statements  and  special 
FCF  language  statements.  The  FCF  language  statements  are  translated  by 
the  precompiler  as  they  are  encountered  and  the  respective  functions  exe- 
cuted. The  FORTRAN  statements  are  written  to  an  output  file  as  they  are 
encountered  if  all  precompiler  functions  are  currently  enabled.  FCF  lan- 
guage statements  are  distinguished  from  FORTRAN  statements  by  the  appear- 
ance of  a P as  the  first  character  in  each  FCF  line. 

The  FCF  language  is  of  a block  structured  and  stream  oriented  modern 
language  design.  It  contains  a number  of  language  statements  that  are 
grouped  into  units  referred  to  as  rules.  Rules  can  be  thought  of  as  either 
a main  program  (the  main  rule)  or  as  subroutines  (rules  invoked  by  another 
rule). 

I 

r 

: 2.1.1  Block  Structure 

t 

A block  structure  is  used  in  grouping  a number  of  language  state- 
ments into  a single  functional  unit  or  in  determining  the  range  of  state- 
ments over  which  certain  program  elements  retain  their  meaning.  Most 
modern  languages  such  as  ALGOL  or  PL/1  nave  block  structures  inherent  in 
their  design.  The  FCF  is  no  exception.  Basic  to  the  structure  of  the 
language  is  the  capability  to  group  statements  by  function  and  conditionally 
bypass  or  execute  the  entire  group.  Such  blocking  capability  combined 
with  good  programming  practice  can  result  in  an  FCF  that  is  more  easily 
understood  by  others  and  which  is  easier  to  modify. 

2.1.2  Precompiler  Control  Statements 

The  most  basic  capability  required  of  the  precompiler  is  the  condi- 
tional or  unconditional  inclusion  of  a block  of  FORTRAN  code.  To  provide 
this,  a number  of  FCF  control  statements  with  programming-language-like 
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syntax  have  been  designed.  As  a result,  the  FCF  control  language  can  be 
thought  of  as  a specialized  Interpretive  progratimlng  language.  Table  1 
provides  a sunnmary  of  the  statements  and  their  basic  function.  As  can  be 
seen,  the  language  elements  provide  Input/output  and  processing  capability 
to  the  FCF  writer  so  that  sophisticated  tests  and  computations  can  be  made 
to  determine  the  form  of  the  final  FORTRAN  output.  Not  shown,  but  in- 
valuable in  providing  capabilities  inherent  in  other  languages,  is  the 
capability  to  use  general  arithmetic  as  well  as  boolean  expressions  as 
elements  of  the  language. 

Precompiler  control  statements  can  be  intermixed  with  FORTRAN 
statements  within  the  FCF.  Clearly,  the  control  Information  is  different 
in  type  from  the  FORTRAN  and  is  physically  distinguishable  by  the  state- 
ment names,  as  well  as  by  the  presence  of  a "P"  as  the  first  character  in 
each  line  of  the  FCF  that  is  used  for  control  statements.  Although  control 
statements  need  not  be  on  separate  lines  from  other  control  statements, 
the  readability  of  the  FCF  is  enhanced  by  good  programming  style. 

The  precompiler  is  designed  to  operate  on  a single  mixed  file. 
However,  the  control  statement  "INVOKE"  allows  for  large  blocks  of  code, 
possibly  consisting  of  just  FORTRAN  statements,  to  be  physically  separated 
from  the  main  rule  or  procedure. 

2.1.3  Special  FCF  Rules 

The  precompiler  is  designed  to  process  a main  rule  or  program. 

When  the  end  of  this  main  rule  is  encountered,  the  precompiler  stops  pro- 
cessing the  FCF,  The  writer  of  the  FCF,  however,  has  the  same  capability 
afforded  by  most  other  prograiming  languages  of  transferring  control  of 
the  precompiler  to  another  rule.  When  this  new  rule  is  complete,  control 
is  transferred  back  to  the  rule  from  which  it  was  called.  This  process  is 
accomplished  through  use  of  the  control  statement  INVOKE.  So,  just  as  in 
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TABLE  1.  SUMMARY  OF  FCF  LANGUAGE  STATEMENTS  AND  BUILT-IN  FUNCTIONS 


FUNCTION 

LEGAL  FCF  STATEMENTS 

SYMBOL  TABLE  OPERATIONS 

DEFINE 

ENTER 

CATENATE 

REPLACE 

DELETE 

CLEAR  TABLE 

SYMBOL  EXISTS 

TABLE  EMPTY 

SET 

INCREMENT 

DECREMENT 

DO  FOR  SYMBOL  TABLE 

INPUT  FILE  OPERATIONS 

INPUT 

FIND 

DO  FOR  EACH  SUBNODE  l 
NODE  EXISTS 

SAVE  POINTER 

rest^Trejointer 

CONDITIONAL 

IF  ...  THEN  ... 

IF  ...  THEN  ...  ELSE 

BLOCK/LOOP 

DO  ...  END 

DO  WHILE  ...  END 
INVOKE 

OUTPUT 

OUTPUT 

MESSAGE 

COMPUTE  PRECOMPILE  TIME 

PARAMETERS 

VALUES 

EXECUTE 

BUILT-IN  FUNCTIONS 

INDEX 

LENGTH 

SUBSTRING 

VALUE 

DEBUG 

ASSERT 

STATUS 

END 

...  END 
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FORTRAN,  PL/ 1 OR  ALGOL,  the  progratmier  can  set  up  arbitrarily  complex 
program  structures.  In  the  FCF,  this  allows  multiple  use  of  certain  groups 
of  precompiler  control  and/or  FORTRAN  statements.  As  in  other  languages, 
there,  undoubtedly,  will  be  control  functions  that  can  be  used  by  other 
FCF  rules.  Such  a subroutine  or  procedure  can  be  used  by  the  FCF  writer 
to  make  programming  tasks  much  easier.  Most  likely,  a library  of  special 
FCF  rules  could  be  used  as  in  other  languages  to  facilitate  the  ease  with 
which  an  FCF  could  be  built. 

A word  of  caution  is  in  order  with  respect  to  using  special  FCF 
rules.  The  precompiler  design  assumes  all  values  are  known  to  and  access- 
ible by  every  rule.  That  is,  all  FLTOPS  variable  values  are  essentially 
global  in  scope.  If  restricted  access  is  required,  the  FCF  writer  is 
responsible  for  establishing,  on  his  own,  mechanisms  for  informing  sub- 
ordinate rules  of  where  information  they  might  need  is  located.  Adequate 
FCF  control  statements  have  been  provided  to  allow  this. 

FCF  rules  are  also  allowed  to  appear  in  the  INPUT  file.  This  allows 
a temporary  change  to  be  made  to  an  FCF  rule  by  simply  copying  it  into 
the  INPUT  file  and  there  making  the  necessary  changes.  The  precompiler 
would  then  process  an  invocation  of  a special  rule  by  checking  all  places 
the  rule  could  be  found  in  the  order  of  a predetermined  priority.  The 
most  likely  priority  would  be  to  check  the  INPUT  file,  the  current  FCF, 
and  lastly,  an  attached  library  file,  using  the  copy  of  the  rule  found 
first. 
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2.2  THE  USER  INPUT  FILE 


As  in  standard  programming  languages,  the  FCF  writer  can  use  an 
input  file  to  ultimately  customize  eventual  program  output.  The  precom- 
piler design  assumes  two  basic  characteristics  of  the  input  file;  one, 
that  it  is  hierarchic  in  nature;  and  two,  that  there  is  a well  defined 
set  of  legal  data  types.  For  a particular  application,  the  detailed  nature 
of  the  input  file  is  determined  by  the  FCF  which  processes  it.  Thus,  the 
FCF  is  designed  so  as  to  produce  the  desired  input  file  properties.  There- 
after, variation  of  only  the  input  file  allows  customization  of  the  FORTRAN 
output  by  the  precompiler. 

2.2.1  Hierarchic  Structure 


User  input  to  the  FCF  is  a hierarchic  arrangement  of  legal  FCF 
input  data  types.  Each  lower  level  is  indicated  by  indenting  exactly 
three  spaces.  Lower  levels  are  logically  subordinate  to  the  higher 
level  that  itimediately  precedes  them.  Thus,  for  example, 

CONSTANTS 

A*1.0 

B-7.2E+7 

C-0 

denotes  that  A,  B,  and  C are  all  constants.  The  only  restriction  on  the 
number  of  levels  possible  for  this  type  of  hierarchy  is  the  allowable  line 
length.  Indentations  of  more  than  three  spaces  are  regarded  as  continua- 
tions of  the  previous  line.  As  an  example  of  how  continuation  statements 
might  be  utilized,  consider  this  example  of  reading  tabular  data. 
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DATA 


X-3 

Y*19,E+3 

TABLE_FOR_CMALFA 
CMALFA  MACH 

-.257  0.6 

-.770  0.65 

-.3  0.7 

CM0»-.1526 

This  type  of  hierarchic  arrangement  provides  an  outline-type  appearance 
which  is  easy  to  read  as  problem  documentation. 

2.2.2  Data  Types 

The  content  of  the  input  file  is  restricted  to  legal  data  types. 
These  consist  of  numbers  (with  or  without  a sign),  identifiers,  strings, 
special  symbols,  comments  and  special  FCF  rules.  Identifiers  begin  with 
an  alphabetic  character  and  may  contain  any  alphanumeric  character  and 
underscore  (_).  An  identifier  cannot  end  with  an  underscore.  Character 
string  literals  are  any  characters,  including  blanks,  enclosed  within  a 
pair  of  apostrophes  (').  Comnonts  are  any  characters  starting  with  /* 
and  ending  with  */.  Soecial  symbols  that  can  be  read  directly,  i.e.,  not 
enclosed  in  apostrophes,  are  *+-/**()=><;0$:.  Any  other 
special  character  must  be  input  as  a character  string  literal. 

Since  algebraic  symbols  can  be  read  directly  from  input,  this  al- 
lows the  FCF  writer  to  transfer  arithmetic  assignment  statements  directly 
from  input  to  FORTRAN  output.  For  example: 

DATA 

DELTA  =*1.9 

GRAV=-XMU*XM1*XM2/R**2 

would  be  suitable  since  the  DELTA  and  GRAV  formulae  contain  only  valid 
input  data  types. 


it 

■] 


Note,  however,  that  the  precompiler  does  not  check  FORTRAN  statements 
for  legal  syntax.  Hence,  assignment  statements  appearing  In  the  Input 
file  should  use  legal  FORTRAN  syntax. 


If  It  Is  necessary  to  substitute  FCF  rules  for  those  In  the  perma- 
nent FCF,  or  to  add  new  rules  to  be  used  temporarily,  this  may  be  done  by 
placing  the  new  rules  In  the  Input  file.  A special  section  of  the  Input 
exists  for  this  purpose.  This  special  section  Is  set  off  from  the  applica- 
tion section  of  the  input  as  illustrated  below. 


APPLICATION 
SECTION  OF 
INPUT  FILE 


FCF  OVERRIDE 
SECTION  OF 
INPUT 


CONSTANTS 

A-2 


I COMPUTATION 

FLUTTER 

INDUCED_DRAG 

C6SHIFT 

/* 


< 


Replacement 

Rule 


FCF: 

/ P SDIFFR: 

\ P IF  .... 


P END  SDIFFR 


In  the  FCF  override  section  of  the  Input,  the  format  Is  Identical 
to  that  used  In  constructing  the  FCF. 


' 


1 
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2.2.3  Interactive  Creation 


Creation  of  the  input  file  to  be  used  by  any  particular  FCF  program 
will  require  special  knowledge  of  the  program  requirements.  As  in  any 
large  program,  where  inputs  may  be  many  and  variable,  it  is  important  to 
document  these  input  requirements  accurately  and  in  detail.  To  avoid 
errors  in  input  and  to  reduce  the  tedium  associated  with  input  structuring, 
many  codes  use  interactive  build  techniques  to  assist  users  in  providing 
the  necessary  inputs  to  the  system.  Inputs  to  the  FCF  are  ideal  candidates 
to  be  created  interactively.  Considerable  thought  has  been  given  to  in- 
cluding explicit  interactive  capabilities  in  the  current  design.  Because 
of  the  interpretive  nature  of  the  FLTOPS  precompiler,  to  explicitly  include 
capabilities  to  build  input  interactively  provides  questionable  utility  at 
considerable  cost. 


However,  the  capability  to  interactively  build  input  files  under 
control  of  non-FLTOPS  software  provides  a desirable  alternative.  This  capa 
bility  currently  exists  in  a rudimentary  sense  with  any  text  editor  program 
available  with  an  interactive  system.  The  degree  to  which  such  an  editing 
system  should  be  enhanced  is  a design  issue  that  is  controlled  both  by 
the  implemented  input  file  structure  and  the  form  of  the  inputs  actually 
used.  Until  more  knowledge  is  gained  in  both  these  areas,  an  interactive 
input  creation  program  cannot  take  an  explicit  form.  It  is,  however,  a 
very  desirable  option  and  could  be  constructed  as  a separate  program  when 
sufficient  information  is  available. 


I 
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2.3  SYSTEM  OUTPUT 


The  FLTOPS  system  generates  three  forms  of  output:  a printed  list 
output,  customized  FORTRAN  source  code,  and  card  images  of  arbitrary  con- 
tent. The  printed  output  consists  of  user  and/or  system  generated  error 
messages,  optional  source  listings  and  various  types  of  debugging/trace 
information  at  the  user's  request.  Although  important  in  testing,  vali- 
dation and  documentation  of  the  FCF  program,  list  output  is  not  the  primary 
output  of  the  FLTOPS  system.  The  goal  is  customized  FORTRAN  code  and  the 
FLTOPS  system  provides  a number  of  mechanisms  for  the  user  to  produce  this 
code. 


The  user  has  the  capability  to  output  whole  FORTRAN  statements 
directly  or  synthesized  FORTRAN  statements  built  up  by  the  FCF  program. 
Each  FORTRAN  statement  is  then  checked  by  the  precompiler  before  being 
actually  written  to  the  output  file  to  perform  any  substitutions  desired 
by  the  user.  These  output  substitutions  can  actually  occur  twice.  Once 
during  actual  execution  of  the  FCF,  referred  to  as  Pass  1 substitution 
and  again  in  a post  processing  operation,  that  strictly  reviews  FORTRAN 
code,  known  as  Pass  2 substitution.  More  detail  on  these  FORTRAN  output 
mechanisms  is  given  in  the  following  section. 

The  FLTOPS  control  language  is  also  capable  of  producing  output 
in  a strict  card  image  format.  Known  as  the  DATA  output  mode,  elements 
written  out  in  this  mode  are  not  altered  in  any  way  by  the  precompiler. 
No  pass  1 or  pass  2 substitutions  are  made  and  no  column  adjustments  are 
made  to  conform  to  FORTRAN  syntax  requirements.  More  detail  on  use  of 
the  DATA  mode  is  given  in  the  discussion  of  the  FLTOPS  OUTPUT  software 
switch  in  Section  3.10. 

2.3.1  PASS1/PASS2  Substitution 


As  FORTRAN  statements  are  encountered  in  the  FCF,  or  as  they  a'"e 
synthesized  by  the  user,  they  are  stored  in  an  output  buffer.  Note  tha^ 
all  FORTRAN  output  is  inhibited  if  the  precompiler  is,  in  fact,  not  fully 
operational  (see  Section  3.10,  for  more  details  on  the  precompiler  FUNCTION 
switch).  During  the  processing  of  the  FCF,  each  individual  element  in 
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the  FORTRAN  statement  currently  in  the  output  buffer  is  compared  against 
entries  in  the  PASS!  symbol  table.  If  the  FORTRAN  element  matches  a symbol 
in  the  symbol  table,  the  value  in  the  PASSl  table  is  substituted  for 
the  FORTRAN  element  before  it  is  written  to  the  output  file.  In  this  way, 
any  FORTRAN  statement  can  be  altered  by  the  user  to  meet  his  requirements. 

The  PASSl  symbol  table  is  a standard  precompiler  table  that  the 
user  can  access  just  like  any  other  symbol  table.  Symbol  entries  in  the 
PASSl  fable  are  substituted  for  their  FORTRAN  counterparts  for  as  long 
as  they  are  In  the  table.  They  can  be  deleted  as  a normal  part  of  the 
FCF  processing  at  any  time.  The  PASSl  table  is  very  helpful  for  inserting 
values,  variable  names,  special  I/O  formats,  etc.,  that  may  be  read 
directly  from  the  input  file  or  computed  internally  by  the  FCF  program. 

Pass  1 substitution  occurs  as  the  FCF  is  processed  by  the  pre- 
compiler. This  means  that  only  those  elements  can  be  replaced  whose  values 
are  known  beforehand.  This  is  not  always  adequate,  however.  For  example, 
if  the  user  wants  to  customize  a FORTRAN  common  statement,  all  variables 
and  their  dimensions  may  not  be  known  at  the  time  the  first  coirmon  state- 
ment is  to  appear.  As  a result.  Pass  1 substitution  may  not  provide 
a convenient  or  adequate  mechanism.  To  provide  greater  flexibility,  the 
precompiler  provides  another  standard  table  known  as  the  PASS2  symbol  table. 

After  the  FCF  has  been  processed,  all  the  FORTRAN  code  that  was 
written  out  is  looked  at  again  if  the  PASS2  table  is  non-empty.  This 
time,  however,  token  substitution  is  made  from  the  PASS2  table.  Although 
PASS2  table  entries  can  be  deleted  or  modified  during  pass  1,  they  have 
no  effect  on  FORTRAN  written  out  until  the  FCF  program  has  been  completed. 

At  this  point,  all  entries  in  the  PASS2  table  are  substituted  for  the 
corresponding  FORTRAN  token  wherever  they  occur  in  the  file  produced  in 
pass  1.  Since  no  changes  can  be  made  to  the  PASS2  table  during  sub- 
stitution, all  changes  are  global  in  scope. 

See  the  example  in  section  4 for  uses  of  pass  1 and  pass  2 sub- 
stitution. 
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3.0  DESCRIPTION  OF  FCF  CONTROL  LANGUAGE 


The  FCF  control  language  provides  FLTOPS  precompiler  users  with  a 
flexible  and  powerful  means  of  customizing  FORTRAN  code.  Combining  standard 
prograiming  language  constructs  with  the  manipulation  of  symbol  table  entries 
and  a set  of  built  in  functions  and  user  accessible  switches,  the  FCF  language 
provides  users  with  a powerful,  yet  simple,  set  of  instructions  to  accomplish 
customization  tasks.  Included  in  the  FCF  language  are  the  capabilities  to 
conditionally  execute  blocks  of  FCF  code  based  upon  arbitrarily  complex 
boolean  expressions,  to  compute  complex  arithmetic  expressions,  as  well  as 
execute  already  compiled  FORTRAN  routines,  and  to  read  data  from  a user 
defined  input  file,  as  well  as  output  predefined  and  synthesized  FORTRAN 
code.  These,  as  well  as  many  other  language  features,  are  discussed  in  more 
detail  in  the  following  sections. 

Table  2 gives  a summary  and  simplified  categorization  of  the  FCF 
control  language  statements.  Note  that  in  addition  to  the  statements  listed, 
precompiler  function  is  also  affected  by  the  values  contained  in  several 
software  switches.  These  switches  are  discussed  in  detail  in  Section  3.10. 

Of  the  statements,  several  belong  to  more  than  one  functional  category. 

This  is  so  because  of  the  complementary  nature  of  the  language  design. 

Of  special  mention  are  those  statements  indicated  as  performing  a test 
function.  Even  though  testing  is  not  their  principal  function,  each  can  be 
used  to  control  FCF  processing.  Each  test  statement  can  be  used  either  by 
itself  or  in  a boolean  combination.  When  used  by  itself,  the  statement 
condition  must  be  met  or  an  optional  user  supplied  FCF  statement  can  be 
processed.  The  result  for  the  user  is  a flexible  set  of  instructions  that 
he  can  use  to  insure  the  integrity  of  FCF  and  input  file  processing.  Each 
statement  is  discussed  in  the  section  representing  its  primary  function 
except  those  indicated  as  built  in  functions  which  are  discussed  in 
Section  3.8. 
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3.1  BASIC  FCF  LANGUAGE  ELEMENTS 

The  FCF  language  consists  of  a number  of  control  statements  that 
can  be  combined  in  a variety  of  ways  with  basic  language  elements  to  form 
syntactically  correct  constructs.  The  sections  that  follow  discuss  not 
only  the  uses  of  the  various  control  statements,  but  also  the  correct  syn- 
tax for  each.  Basic  to  understanding  the  syntax  of  these  commands  is  a 
comprehension  of  the  notation  conventions  of  the  definitions.  The  following 
notation  conventions  are  adopted  for  consistency  and  ease  of  comprehension. 

< > Items  appearing  within  these  symbols  refer  to  an 

element  such  as  another  FCF  statement  or  a basic 
language  element  defined  below. 

r 1 Items  appearing  within  these  sumbols  are  optional 

and  appear  only  at  the  discretion  of  the  user. 

<•..  y Special  notation  indicating  that  the  syntax  pattern 
already  established  can  be  repeated  as  often  as 
necessary. 

Any  character  appearing  in  a syntax  description  not  bracketed  by  < > 
must  appear  exactly  as  written. 

Many  concepts  that  help  in  understanding  the  use  of  the  language 
are  not  language  statements  themselves,  but  elements  of  the  language.  Al- 
though a rigorous  syntactic  description  of  all  language  elements  is  given 
in  Section  6,  an  informal  discussion  of  these  basic  concepts  is  provided 
below  to  make  clearer  the  proper  use  of  the  FCF  language  statements. 

* In  the  context  of  symbol  table  operations,  the 

asterisk  is  a special  symbol  that  refers  to  the 
last  data  element  successfully  read  from  the  input 
file.  In  arithmetic  expressions,  it  refers  to 
multiplication. 

Example:  See  ENTER,  SUBSTRING,  etc. 
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<word> 


<nutnber> 


<str1no> 


The  "at"  sign  is  a special  symbol  that  refers  to  the 
current  pointer  value.  In  the  context  of  symbol  table 
operations.  It  refers  to  the  symbol  table  pointer.  In 
the  context  of  input  file  operations,  It  refers  to  the 
Input  file  pointer. 

Example:  See  ENTER  and  FIND 

Any  alphabetic  character  followed  by  zero  or  more 
alphanumeric  characters  or  underbars  (_).  A <word> 
cannot  end  with  an  underbar,  nor  can  two  underbars 
be  joined  together.  A <word>may  begin  with  a pound 
sign  (#)  as  long  as  there  Is  at  least  one  alphanumeric 
character  following  It.  The  # by  Itself  is  not  a word  . 
A word  beginning  with  # Is  most  useful  for  estab- 
bllshlng  symbol  names  that  will  be  used  In  pass  1 or 
pass  2 substitutions. 

Examples:  ABC  A_B  X7B  #A_B 

Any  integer,  floating  point,  or  exponential  represen- 
tation of  a numeric  quantity. 

Examples:  7 8.93  1.02E-5 

Any  characters  that  appear  between  standard  string 
delimiters  (normally  '). 

Examples:  'THIS  IS  A STRING' 

'ANOTHER  STRING*$+.' 


<statement>  Any  legal  FCF  language  statement,  that  appears  in 
Table  3 except  for  built  In  functions.  Built  in 
functions  can  be  used  as  a part  of  many  statements 
but  cannot  be  used  by  themselves. 

Examples:  SYMBOLJXISTS 
TABLEJMPTY 
IF... THEN 
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(.table  name) 


An  FCF  element  that  identifies  the  name  of  a table 
where  values  can  be/are  stored.  It  is  most  often  a 
<word>,  but  can  be  any  <string  expression).  For  example, 
an  asterisk  or  VALUE  function  can  be  used  to  reference 
a table  name  read  from  input  or  symbol  table  respectively. 
Examples:  TABLE_17 
TABLE  NAME 


<symbol  name)  An  FCF  element  that  identifies  the  name  of  a symbol  with 
which  values  are  associated.  It  is  most  often  a <word) 
but  can  be  any  <string  expression).  An  asterisk  (*) 
or  VALUE  function  may  be  used  to  reference  a symbol  name 
read  from  input  or  a symbol  table  respectively. 

Examples:  SYMB0L_17 
SYMBOL  NAME 


<arithmetic 

expression) 


Any  algebraic  combination  of  a VALUE,  LENGTH,  or  INDEX 
function,  <number)  or  <word)  or  <word)with  <subscripts)  . 
Parentheses  can  be  used  to  determine  the  order  of  operations. 
A <word)  with  <subscripts)  is  assumed  to  be  a <table  name)  ; 
a <word>  without  < subscripts)  is  assumed  to  be  a < symbol 
name)  which  is  an  entry  in  the  current  default  symbol  table 
The  order  of  evaluation  of  these  expressions  follows 
standard  FORTRAN  conventions. 

Examples:  7 * VALUE  (A,B) 

A**5*(B+8)  * X(5) 


<string 

expression) 


A string  expression  is  a <number)  , a<word'^,  a<word) 
with<subscript)  , a <string),  an  * (asterisk)  referring 
to  the  last  element  read  from  input,  or  an  (.arithmetic 
expression).  It  can  be  simply  a VALUE  function  or  a 
SUBSTRING  function. 

Examples:  'STRING  EXPRESSION' 

7.95321E10 

A * VALUE  (TABLEl,  SYMB0L2)  + 5 


VALUE  (X,Y) 

SUBSTRING  {'ABC , 1,1) 


<vdl  ue> 


The  quantity  that  is  actually  entered  into  a symbol  table. 
It  can  be  any  <string  expression>.  If  the  <value>  is 
simply  a <word>  then  it  is  interpreted  as  referring  to  a 
symbol  entry  in  the  default  symbol  table.  The  table  entry 
corresponding  to  this  symbol  is  retrieved  and  used  as  the 
\val  u^ 

Examples:  'THIS  IS  A SYMBOL  ENTRY' 


97.5  + A*B 
A (i.e.. 


i 

1 


'A'  (i 
B{5.3) 


.e. 


refers  to  the  value  of  symbol 
, refers  to  letter  A as  a val 


A) 

ue) 


<subscripts> 


< forma t> 


Up  to  three  occurrences  of  an  <arithmetic  express ion>, 
separated  by  commas  and  enclosed  with  parentheses. 
Examples:  (7,  10,  2) 

(7  * N) 

(2.  VALUE(Y,X)  + 1)_ 

The  format  expression  allows  the  user  to  transform  the 
preceding  language  element  to  the  desired  fo.rm.  It 
consists  of  either  the  word  FORMAT  with  a parenthesized 
FORTRAN  compatible  FORIW  element  or  the  special  short- 
hand notation  *>(an  arrow)  followed  by  a FORTRAN  com- 
patible FORMAT  element. 

Examples:  F0RMAT(A8) 

F0RMAT(I5) 

= > F10.4 
= > E12.5 


< input  tree>  A <^word>or  |3  followed  by  zero  or  more  occurrences  of. 
(period)  and  a <word>. 

Examples:  INPUT. TREE. NODE 

(3. NEXT  LEVEL. DOWN 


A 


i 

n 


Jl 
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<boo1ean  The  boolean  expression  is  the  most  complicated  language 

expression)  element.  It  consists  of  relational  expressions,  SYMB0L_ 
EXISTS  and  TABLE_EMPTY  statements  joined  by  AND,  OR  and 
NOT.  It  may  also  be  a single  INPUT  statement.  Lastly, 
it  may  be  NODE_EXISTS  or  FIND  followed  by  an  <input  tree) 
specification  enclosed  in  parentheses.  Except  for  the 

INPUT  statement,  these  elements  may  be  joined  in 
arbitrarily  complex  expressions  using  parenthesis  as 
logical  separators.  The  order  of  completion  of  these 
expressions  is  left  to  right  with  parenthetical  groupings 
taking  precedence. 

Examples:  NODE_EXISTS  (INPUT. TREE. NODE) 

INPUT  ('A') 

VALUE  (A,B)>=  0 
7 * VALUE  (N)  + 1^^=  VALUE  (X) 

SYMBOLJXISTS  (A,B)  AND  VALUE  (A,N)>0 
NOT  (VALUE(A,B)  = 7 AND  SYMBOLJXISTS  (B,C)) 
FIND  (A.B)  OR  VALUE  (X,Y)  = 0 


3.2  SYMBOL  TABLE  OPERATIONS 


Central  to  the  capabilities  of  the  FCF  language  is  the  ability  to 
store  and  manipulate  entries  within  a symbol  table.  Symbol  tables  are 
collections  of  entries  that  are  referenced  by  either  a table  name  / symbol 
name  combination,  or  a table  name  / subscript  combination,  or  simply  by 
symbol  name.  These  table  entries  are  called  values  and  are  string  literals 
of  arbitrary  length. 

Several  symbol  table  operations  allow  the  use  of  a shorthand  notation 
in  which  the  table  name  need  not  be  explicitly  supplied  in  the  statement 
syntax.  In  these  instances,  the  symbol  is  assumed  to  be  an  entry  in  what 
is  known  as  the  default  symbol  table.  Most  symbol  table  operations  can 
explicitly  reference  the  default  symbol  task  by  using  the  key  word  DEFAULT 
in  the  table  name  field  of  the  statement  or  implicitly  by  the  syntax  of  the 
statement.  Predefined  as  the  FLTOPS  symbol  table,  the  default  symbol 
table  can  be  reset  by  the  user  with  the  DO  FOR  SYMBOL  TABLE  conmand. 

All  symbol  table  operations  which  alter  the  contents  of  a symbol 
table  have  an  optional  format  control  capability.  This  format  control 
allows  the  user  to  specify  the  format  that  the  data  is  to  take  before  it 
is  entered  into  the  symbol  table.  Thus,  if  an  arithmetic  calculation  is 
to  be  made,  a format  statement  that  immediately  follows  the  computation  will 
insure  that  the  data  is  entered  in  the  form  needed  by  the  user.  The 
format  specification  itself  can  be  any  legal  FORTRAN  format  specification 
such  as  AlO  or  15.  The  exact  nature  and  breadth  of  formating  capabilities 
is  left  as  an  implementation  option.  At  the  very  least,  the  A,E,F,  and  I 
FORTRAN  format  specification  types  should  be  implemented. 

The  following  are  descriptions  of  the  table  manipulation  statements 
available  to  users. 


CATENATE 


SYNTAX:  CATENATE(<tabl e name> .< Symbol  name)  <value>l<  format^ 

or  CATENATE  (DEFAULT,  v symbol  name>  , <value  >|<fomat  >)!<'...>  | } 
or  CATENATE(<C  table  name)  ^subscripts),  ^val  ue>  [<  format^ 
or  CATENATE(i3,  <value)  ^format!^  [7  <•••)]]  ) 

The  CATENATE  statement  allows  the  user  to  append  additional  value 
strings  onto  existing  table  entries.  If  a table  location  has  no  value 
associated  with  it,  the  CATENATE  behaves  as  an  ENTER  coimand.  As  many 
values  can  be  catenated  to  a single  location  with  one  command  as  desired. 
Any  value  catenated  can  be  followed  by  a format  specification. 


Examples : 

ENTER  ( A,  B,  'THE  NEW  ') 

CATENATE  ( A,  B,  'AIRPLANE  ') 

The  string  AIRPLANE  is  appended  to  the  current 
value  entry  for  symbol  B in  Table  A,  making  the 
string  THE  NEW  AIRPLANE. 

ENTER  ( A,  C,  'FLY  ') 

CATENATE  ( A,  B,  'CAN  ',  VALUE(A,C)) 

The  words  CAN  FLY  are  catenated  to  the  contents  of 
symbol  B in  table  A. 

SET  ( N « 3.4  ) 

SET  ( M > 4 ) 

ENTER ( A, B) 


CATENATE  ( .3.  'FASTER  THAN  MACH',  N/M  FCRMAT(F3.1 ) ) 

The  string  FASTER  THAN  MACH  2.1  is  appended  to  the 
current  contents  of  A, 3.  Note  that  the  arithmetic 
exoression  is  evaluated,  then  converted  via  the  format 
F3.1  to  the  desired  form.  If  the  format  statement  oao 


not  appeared,  the  actual  string  catenated  could  have 
been  something  similar  to  2.09999998  due  to  round  off 
error  in  the  calculation. 

CATENATE  (DEFAULT,  AB,  VALUE  (A,B)) 

Catenated  at  the  end  of  symbol  AB  in  the  currently 
defined  default  symbol  table  are  the  contents  of 
symbol  B in  table  A. 
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CLEARJABLE 

SYNTAX:  CLEARJABLE JABLE  « table  name» 

All  entries  for  the  specified  table  name  are  deleted.  This  action 
frees  up  table  space  used  for  unneeded  or  old  tables.  All  symbols  and/or 
associated  values  are  removed  from  the  table.  The  switches  and  flags  that 
are  predefined  entries  in  the  FLTOPS  symbol  table  cannot  be  deleted  or 
cleared,  although  user  supplied  entries  in  the  FLTOPS  table  can. 

Example: 

CLEARJABLE  (A) 

Table  A no  longer  has  any  symbol  and/or  value  entries. 


DECREMENT 


SYNTAX:  DECREMENT C<symbol  name>l 

A value  of  one  (1)  is  subtracted  from  the  current  value  associated 
with  the  indicated  symbol  in  the  currently  defined  default  symbol  table. 

Example:  DECREMENT (N) 

If  the  current  value  of  N was  1,  then  the  new  value  of 
N would  be  0. 
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DEFINE 


SYNTAX:  DEFINE  <table  name)  <subscn‘pts> 

DEFINE  <tab1e  name)  AS  Stable  name)  [.<•■■>] 

DEFINE  <table  name)  AS  NULL  [T<.  ..J 

The  DEFINE  statement  allows  FCF  users  to  establish,  or  remove, 
special  characteristics  identified  with  the  indicated  symbol  tables. 

Sy  use  of  the  DEFINE  command  the  FCF  user  can  either  establish  dimensions 
for  symbol  tables  or,  an  empty  or  not  yet  established  table  can  be  equivalenced 
to  a new  or  existing  table  so  that  table  entries  can  be  referenced  by  either 
table  name. 

By  establishing  dimensions  for  a symbol  table,  the  user  can 
reference  the  associated  table  entries  by  subscript  rather  than  by  symbol 
name.  As  such,  these  defined  tables  are  similar  in  appearance  and  use  to 
array  variables  in  other  programming  languages.  Standard  subscripting 
conventions  are  in  effect.  Any  tables  whose  entries  are  accessed  via 
subscript  notation  cannot  have  entries  accessed  by  symbol  name  and  vice 
versa.  Such  DEFINE  statements  can  appear  anywhere.  The  same  table  name 
having  dimensions  assigned  more  than  once  uses  those  established  in  the 
last  assignment.  All  current  table  entries  are  deleted  when  a table  is 
defined  to  be  a subscript  accessible  table.  Thus,  if  a table  were  being 
used  in  which  its  entries  were  referenced  by  various  symbol  names  and 
appeared  in  a DEFINE  statement  as  a subscripted  table,  all  its  current 
entries  would  be  automatically  deleted. 

Another  use  of  the  DEFINE  statement  is  to  establish  table  name 
equivalences.  More  accurately  referred  to  as  the  DEFINE... AS  conmand, 
this  statement  enables  users  to  refer  to  the  same  table  entries  by  more 
than  one  table  name.  The  first  table  name  in  the  list  must  be  a new 
(not  previously  used  table)  or  a table  that  is  empty  or  a table  which 
has  been  previously  equivalenced  to  some  other  table.  The  second  table 
name,  inmediately  following  the  AS,  is  the  table  to  which  the  first  is 
equivalenced.  There  are  no  restrictions  on  the  prior  defined  charac- 
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teristics  of  this  table.  Each  reference  to  the  first  table  name  actually 
performs  operations  on  entries  in  the  table  associated  with  the  second 
table  name.  Many  table  names  can  be  equivalenced  to  a single  table  either 
directly  or  through  an  "equivalence  chain".  (See  example  below).  Note 
any  cycles  in  an  equivalence  chain  are  indicated  as  severe  errors. 

Both  the  dimension  and  equivalence  characteristics  can  be  removed 
at  any  time  by  use  of  the  DEFINE... AS  NULL  command.  The  table  name  iden- 
tified by  this  command  has  its  dimensions  and  any  direct  equivalences 
removed.  If  the  table  so  named  is  a "real"  table,  i.e.,  one  that  has 
not  been  equivalenced  or  one  that  is  the  last  table  in  an  equivalence 
chain,  all  of  its  entries  are  also  deleted.  Note  that  in  this  instance 
a general  warning  message  is  issued  indicating  the  table  has  been  emptied. 

Example: 

SET  ( N = 20  ) 


DEFINE  X (N,  3 ) 

Table  X is  defined  as  a 20  x 3 matrix.  (Note  that  the 
value  of  N (i.e.,  20)  is  retrieved  from  the  default 
symbol  table.) 

DEFINE  INDEPENDENT  AS  X 
DEFINE  DEPENDENT  AS  Y 
DEFINE  DEPENDENT  ( N + 2 ) 

A table  which  is  identified  as  the  independent  variable 
is  associated  with  table  X.  All  characteristics  of  X 
are  assumed  by  INDEPENDENT,  and  similarly  for  DEPENDENT 
and  Y.  Table  DEPENDENT  and  consequently  table  Y is 
defined  as  a 22  element  array.  The  dimensions  are 
actually  associated  with  Y 
SET  ( I = 0 ) 

DO  WHILE  I<=  N 'll 

INCREMENT(I) 

ENTER  (DEPENDENT(I),  INDEPENDENT  (1,1)  * INDEPENDENT  (1,2)  + 

INDEPENDENT  (1,3)) 


END 


All  entries  directed  into  table  DEPENDENT  are  actually 
beinq  stored  in  an  area  associated  with  the  table  Y. 
DEPENDENT  is  a pseudo-table  in  that  it  simply  points  to 
Y. 

DEFINE  DEPENDENT  AS  NULL 

A reference  to  DEPENDENT  no  longer  will  retrieve/store 
entries  from  table  Y. 

DEFINE  TABLE  AS  INDEPENDENT 

An  equivalence  chain  is  established.  TABLE  points  to 
INDEPENDENT  which  in  turn  points  to  X.  A reference  to 
TABLE  actually  references  entries  in  X. 


DELETE 


SYNTAX;  DEL£TE«table  name>,  <synibo1  nafne» 
or  OELETE«table  name>  <subscnpts>) 
or  DELETE «symbo1  name» 

The  DELETE  statement  provides  the  capability  to  delete  individual 
table  entries.  Both  the  symbol  (if  applicable)  and  the  associated  value 
entry  are  removed  from  the  table. 

Example: 

DELETE(A,B) 

DELETE(X(17)) 

DELETE (N) 

Both  the  17th  value  in  Table  X and  symbol  B with  its 
associated  value  in  Table  A are  removed.  Symbol  N is 
deleted  from  the  default  symbol  table. 
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DO  FOR  SYMBOL  TABLE 


SYNTAX:  DO  FOR  SYMBOL  TABLE  table  name 


The  DO  FOR  SYMBOL  TABLE  block  construct  allows  the  user  to  change 
the  definition  of  the  default  symbol  table  name  to  the  indicated  table. 

The  use  of  the  dr'^ault  symbol  table  within  the  SET.  INCREMENT,  DECREMENT, 
DELETE  VALUE,  REPLACE  and  CATENATE  statements  can  then  be  expanded  to  any 
table  not  using  subscripts  to  reference  its  contents.  Since  tables  accessed 
via  subscripts  have  no  symbols,  it  is  meaningless  to  use  a default  symbol 
table  with  such  tables.  The  default  symbol  table  name  is  initially  set  to 
FLTOPS.  Nesting  of  DO  FOR  SYMBOL  TABLE  blocks  is  allowed  to  an  arbitrary 
depth.  On  encountering  the  END  statement  for  the  block,  the  default  symbol 
table  reverts  back  to  the  previously  defined  default  symbol  table. 


Example : 


DO  FOR  SYMBOL  TABLE  A 


SET(SWITCH='ON' ) 


The  value  of  symbol  SWITCH  in  Table  A is  set  to  ON. 
At  the  end  of  the  block,  the  default  symbol  table  is 
reset  to  FLTOPS. 

DO  FOR  SYMBOL  TABLE  A 

SET  ( N = 0 ) /*  N in  table  A set  to  J ♦ 

DO  FOR  SYMBOL  T.ABLE  3 

SET  ( N = 0 1 . * N in  table  3 set  to  O'*/ 

DC  WHILE  Ns=10 


INCREMENT(N)  /*1  added  to  N in  table  B */ 


END 

/*  The  inner  default  symbol  table  definition  ends  and  a 1 
is  added  to  N in  table  A V 
INCREMENT(N) 

END 

/*A  no  longer  is  the  default  symbol  table  */ 

This  example  shows  the  use  of  nested  default  symbol  tables.  Note 
that  N in  symbol  table  A is  not  affected  by  the  increments  performed  in 
the  inner  DO  FOR  SYMBOL  TABLE  block. 


ENTER 


SYNTAX:  ENTER(<table  name>,  < symbol  name),  <val ue) l^format^  ) 
or  ENTER(<[ table  name),  < symbol  name)) 
or  ENTER(<table  name)  ^subscripts),  <val ue)  (<format^  ) 
or  ENTER(<^ table  name)  <^subscri pts)) 
or  ENTER((3,  val ue)  [<format^  ) 

or  ENTER  (DEFAULT,  <symbol  name)  , <value>  [2<  format^) 
or  ENTER  (DEFAULT,  < symbol  name)  ) 


The  ENTER  statement  allows  the  user  to  enter  values  into  symbol 
tables.  Symbol  tables  are  referenced  in  either  of  two  ways:  a table  name 
followed  by  a symbol  name  or  a table  name  followed  by  subscripts.  In  the 
latter  case,  the  table  name  specified  must  have  appeared  in  an  earlier 
DEFINE  statement  or  a fatal  error  occurs.  When  no  vvalue^  occurs  in  the 
argument  list,  the  table  name  and  symbol  name  (or  subscript  location)  are 
located  but  no  value  entry  is  made.  Use  of  the  ENTER  statement  with  D as 
the  first  argument  would  enter  a value  at  the  last  symbol  table 
position  that  was  referenced.  Before  values  are  actually  entered, 

they  can  be  reformatted  according  to  the  specification  shown  in  the 
optional  format  statement.  The  user  can  use  the  key  word  DEFAULT  to 
enter  data  into  the  default  symbol  table.  A short  hand  form  that 
accomplishes  the  same  thing  is  provided  through  the  SET  command. 


Examples ; 

ENTER(A,B. 'C‘ ) 

In  this  example,  string  C is  entered  as  the  value  for 
symbol  B wi thi n Tabl e A. 

ENTER(X(17).  VALUE(A.Y)*2=:"  15) 

In  this  example,  the  value  of  Y in  symbol  table  A is 
multiplied  by  two  and  the  product  is  entered  as  the 
17th  value  in  Table  X.  The  value  is  formatted  in  an 
15  format  before  being  entered  into  X(17). 

ENTER  (A.F) 

ENTER(3.  'DELAYED  ENTRY'  F0RMAT(A15)) 


.1- 1 B 


Symbol  F in  Table  A is  located;  string  DELAYED  ENTRY 
is  entered  as  the  value  for  F if  no  other  symbol  table 
operations  were  performed  between  them.  Note  that 
the  original  string  has  13  characters  and  an  A15  format 
is  specified.  In  this  instance,  two  blanks  would  be 
appended  to  the  string  before  it  was  stored. 


INCREMENT 


SYNTAX:  INCREMENT(<symbol  name» 

The  INCREMENT  statement  adds  one  (1)  to  the  value  of  the  indicated 
symbol  in  the  currently  defined  default  symbol  table. 

Example:  INCREMENT(N) 

If  the  value  associated  with  N was  1,  then  the  new  value 
after  this  statement  would  be  2. 
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SYNTAX;  REPLACE  ( \table  name^  , \syinbol  name''  , <value\  \value^ 


; s forma t> 


,<arithmetic  express ionN  ) 


01  REPLACE  ( DEFAULT , V,  symbol  name'''  , \valLie  » <^value^[\format'- 
[^arithmetic  express io^^|  ) 


or  REPLACE  ( \table  name'' ^subscripts ' 


\ 


value''  , 'Lvalue' 


<Lformat>j  , (arithmetic  expression^j) 
or  REPLACE(i3,  (value)  , (val ue'' !<formac [ , ^ari  thmeti c 


expression '' 


) 


The  REPLACE  statement  provides  the  capability  to  do  substring 
replacement  within  already  existing  table  entries.  The  first  <value> 
string  is  the  string  to  be  replaced.  If  this  string  is  a substring  of 
the  identified  table  entry,  it  is  replaced  with  the  optional  second 
<value>  string.  This  second  string  can  optionally  be  formatted  according 
to  the  format  supplied  by  the  user  before  being  inserted.  If  the  first 
(value)  is  a null  string  (i.e.,  the  second  ( va 1 ue)  is  catenated  at  the 

beginning  of  the  value  in  the  symbol  table.  The  REPLACE  statement  does 
a global  replace  of  all  occurrence  of  the  first<value>  at  the  indicated 
location.  If  the  optional  ^arithmetic  expression>is  present,  the<ari thmetic 
expression)  i s evaluated,  and  truixjated  to  integer  form.  The  resultant 
integer  reflects  the  numbe;-  of  occurrences  of  the  first  <value>  that 
are  to  be  replaced  by  the  second  <value>. 


Examples ; 

ENTER(A,B, ‘EXAMPLE- 1 ' ) 

R£PLACE(A.8.1,-3.I*'.3  = >12) 

The  entry  for  symbol  3 in  Table  A is  ch.^nged  to 
EXAMPLE--T.  Note  tnat  the  calcul  atic's  are  ?erfor'"t.d; 
then  the  resultant  value  reformatted  into  a two  digit 
integer  fonnat. 

E.NTER(A.D) 

R£?LACE;a. 

This  resi/its  in  symool  3 in  Table  A 'laving  the  value 
EXAMPLE-',  i.e.,  the  first  - '.vas  aeleted. 

REPLACEiA.3.  " . 'NElv  '' 

■his  results  in  NEW  oeing  catenated  at  tne  beqinn’ng 
of  the  sympol  taole  entrv.  So  tnat  the  entrv  *or  3 
in  Tao’e  A oecomes  'iE'.v  EXAMPLE-' 


SET 


SYNTAX;  SET«symbol  name>  * <val ue>  ^format^  ) 
or  SET « symbol  natne>) 

The  SET  command  is  a shorthand  form  of  the  ENTER  coitmand.  The 
symbol  is  assumed  to  be  in  the  currently  defined  default  symbol  table. 
The  second  form  of  the  SET  command  simply  enters  the  symbol  into  the  de- 
fault symbol  table  and  positions  the  SYMBOL_TABLE_POINTER  accordingly. 

Examples: 

SET(B  = 8*X(7)  + 15  * VALUE(A,B)  F0RMAT(F10.4) ) 

SET(FUNCTION  =»  'SYNTAX') 

The  first  statement  sets  the  value  for  symbol  B in 
the  default  symbol  table  to  be  the  result  of  the 
arithmetic  expression.  The  format  statement  insures 
the  user  the  result  is  in  a form  he  can  use.  The 
second  statement  sets  symbol  FUNCTION  in  the  default 
symbol  table  to  be  the  string  SYNTAX.  An  alternate 
way  of  doing  the  second  example  might  be: 
SET(FUNCTION) 

ENTER (0, 'SYNTAX') 

The  SET  command  here  simply  positions  the  SYMB0L_ 
TABLE_POINTER  for  subsequent  entry  of  the  indicated 
value. 
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SYMBOL  EXISTS 


SYNTAX:  SYMBOL_EXISTS«table  nauie^,  <syiiibo1  name>)  (ERROR:<statenient^ 
SYMBOL_EXISTS«symbol  name»  (ERROR:  <statement  ^ 

The  SYMBOL_EXISTS  provides  the  capability  for  the  user  to  test  to 
insure  that  the  specified  symbol  name  is  in  fact  an  entry  in  the  desired 
table.  In  the  first  form  of  the  statement  the  table  name  is  explicitly 
provided  by  the  user.  In  the  second  form,  the  symbol  is  tested  to  see 
if  it  exists  in  the  currently  defined  default  symbol  table.  If  the  symbol 
is  not  in  the  table,  the  optional  ERROR:  condition  is  executed.  If  the 
ERROR:  condition  is  not  present,  a default  error  message  is  given.  If 
the  symbol  is  present,  the  ERROR:  condition  is  bypassed.  A SYMBOL_EXISTS 
statement  may  appear  in  a boolean  expression,  but  without  the  optional 
ERROR:  condition. 

Example: 

SYMB0L_EXISTS(A,6)  ERROR;  DO 

END 

SYMBOL_EXISTS(N)  ERROR:  MESSAGE  (‘GW:  N NOT  AVAILABLE’) 

If  symbol  B has  not  been  entered  into  Table  A,  the 
ERROR;  condition  is  taken  and  the  DO  block  executed. 
Otherwise,  all  statements  within  the  DO  block  are 
bypassed  except  for  syntax  checking.  In  the  second 
SYMBOL_EXISTS  construct,  the  symbol  N is  tested  to 
see  if  it  is  available  in  the  default  symbol  table; 
if  not,  the  message  is  issued. 
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TABLE  EJ1PTY 


SYNTAX : TABLEJMPTY  « tab!  e name»  [ERROR ; <statement>] 

The  TABLE_EMPTY  coinnand  allows  the  user  to  be  sure  that  a specified 
table  has  no  entries.  The  optional  ERROR:  condition  is  taken  only  if  the 
Indicated  table  does,  in  fact,  have  an  entry.  If  no  ERROR:  condition  is 
present,  a default  error  message  Is  given.  The  TABLE_EMPTY  statenjent  may  be 
used  in  a boolean  expression,  but  without  the  ERROR:  option. 

Example: 

TABLE_EMPTY(A)  ERROR:  MESSAG£(G, 'W:TA8LE  A NOT  EMPTf  ) 

If  Table  A is  not  empty,  the  ERROR:  condition  is  ex- 
ecuted and  the  general  class  warning  message  is  written. 


3.3  INPUT  FILE  OPERATIONS 


The  input  data  file  read  by  the  FCF  language  is  assumed  to  be 
hierarchic  in  form.  A simple  way  to  think  of  the  input  file  is  to  view 
it  as  a tree  structured  file.  Figure  2 shows  a simplified  example  of 
how  an  input  file  might  be  structured  and  its  corresponding  tree  structure. 
Tree  structures  are  represented  by  nodes,  with  the  hierarchy  determined 
by  the  different  levels  of  the  nodes.  With  respect  to  input,  the  top  of 
the  tree  can  be  thought  of  as  the  beginning  of  the  file.  The  first  line 
of  data  appearing  in  the  example  is  assumed  to  be  the  first  node,  and 
the  second  line  the  second  node,  both  on  the  same  level.  However,  there 
are  input  lines  subordinate  to  this  line,  and  they  are  represented  as 
lower  level  nodes  in  the  tree  structure.  The  remaining  input  is  treated 
similarly,  with  the  number  of  levels  and  nodes  dependent  only  upon  space 
limitations. 

The  input  file  operations  are  designed  to  provide  the  FCF  writer 
with  flexible  access  to  all  input  data.  The  INPUT  statement  reads  data 
in  a token-by-token,  stream-oriented  fashion.  Each  node  in  the  input  tree 
consists  of  all  elements  on  a given  line  including  any  continuation  lines. 

As  shown  in  figure  2,  node  (2,2,2)  in  the  hierarchic  input  structure  actuall 
is  made  up  of  more  than  one  line  in  the  input  file.  Since  these  succeeding 
lines  are  continuations  of  the  previous  line,  they  are  all  assigned  to 
the  same  node  in  the  tree.  The  INPUT  command  is  used  to  read  elements 
on  any  specific  node  at  the  tree.  The  FIND  command  is  used  to  find  any 
specified  node  in  the  tree,  and  the  NODE_EXISTS  comnand  is  used  to  test, 
without  altering  the  current  input  node  position,  for  the  existence  of  a 
particular  node  in  the  tree.  These,  combined  with  save  and  restore 
operations  of  the  current  location  in  the  input  file,  provide  FCF  users 
with  a flexible  and  potentially  very  fast  input  file  processing  capability. 
Below  is  a syntax  description  and  examples  of  their  use  for  all  input 
fi le  operations . 
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SAMPLE  INPUT  FILE: 


NODE  IN  TREE 


(BEGINNING  OF  FILE) 
FIRST  LINE 
SECONIT  LINE 

SUBORDINATE  LINE 
ANOTHER  LINF 
DATA^ALUE 
MORE  DATA 

COITTINUATION 
LAST  LINE  THIS  LEVEL 
NEXT  LINE  FIRST  LEVEL 


0 

1 


2,1 

2.2 

2,2.1 

2.2.2 

2.2.2 

2.3 

3 


CORRESPONDING  TREE  STRUCTURE: 
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00  FOR  EACH  SUBNOOE  OF 


SYNTAX:  DO  FOR  EACH  SUBNOOE  OF  <input  tree> 

end' 

or 

DO  FOR  EACH  SUBNOOE  OF  @ 

END* 

This  DO  block  allows  the  user  to  perform  the  same  operations  for  each 
of  a group  of  subnodes  on  the  input  tree.  If  there  are  no  subnodes  at  this 
point  in  the  input  file,  a warning  message  is  written  and  the  DO  block  is 
checked  only  for  syntax;  no  operations  are  performed.  In  the  second  form 
of  this  DO  construct,  the  0 implies  that  no  further  searching  of  the  input 
will  be  done  other  than  that  positioning  required  for  each  subnode. 

The  input  parsing  pointer  is  restored  to  its  initial  position  at 
the  completion  of  the  loop. 

Example: 

SET(N*0) 

DO  FOR  EACH  SUBNODE  OF  ARRAY. VALUES 
INPUT(CONSTANT^ 

INCREMENT(N) 

ENTER{A(N),*) 

END 

This  example  shows  how  constants  might  be  read  into  a 
Table  A.  The  input  file  is  searched  for  ARRAY. VALUES 
and  all  subnodes  are  entered  into  symbol  Table  A.  Another 
way  of  doing  this  conditionally  might  be: 
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IF  FIND  (ARRAY. VALUES) 

THEN  DO 
SET(MAX  = 10) 

DEFINE  TAB(MAX) 
SET(TABLE_NAME  = 'TAB') 
INVOKE  TABLE_READ 
END 


TABLE_READ:= 

DEFINE  TABLE  AS  VALUE (TABLEJAME) 

SET(N=0) 

DO  FOR  EACH  SUBNODE  OF  ? 

INPUT (CONSTANT)  ERROR:  MESSAGE( I , 'S: INCORRECT  DATA  IN  INPUT  FILE' 
INCREMENT(N) 

TP  N<=  MAX  THEN  ENTER(TABLE(N)  ,*) 

END 

DEFINE  TABLE  AS  NULL 
END  TABLE_READ 

In  this  example,  a test  is  made  to  see  if  there  is  a 
second  level  node  named  VALUES  subordinate  to  a first 
level  node  named  ARRAY  in  the  input  file.  If  so,  a 
table  is  dimensioned  to  contain  at  most  10  elements. 

The  rule  to  be  invoked  expects  the  equivalenced  table 
name  to  be  passed  in  symbol  entry  TABLE_NAME  in  the 
default  symbol  table.  It  also  expects  to  have  the 
maximum  allowable  subscript  passed  as  symbol  MAX  in 
the  default  table. 
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The  rule  can  be  elsewhere  in  the  FCF,  in  the  input  or 
in  a library.  The  rule  assumes  that  the  pointer  has 
already  been  positioned.  Data  values  are  read  into 
TABLE  which  have  been  equivalenced  to  a user  supplied 
table  name. 

The  rule  TABLE_READ  is  invoked  to  actually  input  the  values. 
Note  that  the  DO  FOR  EACH  SUBNODE  OF  loop  implicitly  saves 
the  input  pointer  position  which  is  pointed  at  the  next 
character  after  VALUES,  a subnode  of  ARRAY.  In  the  first 
example  the  pointer  position  saved  was  the  last  position 
referenced  before  ARRAY.  VALUES  was  found. 


FIND 


SYNTAX:  FIND«input  tree»  [eRROR:  <statement3 

The  FIND  statement  allows  the  FCF  writer  to  directly  access  any 
node  in  the  input  hierarchy.  If  a <word>  is  the  first  element  in  the  input 
tree  specification,  the  search  begins  at  the  top  of  the  input  file  and 
proceeds  to  each  successive  level  until  the  required  input  node  is  found. 

If  the  tree  specification  begins  with  an  at  sign  ((?),  the  search  for  the 
required  node  begins  at  the  current  input  pointer  position.  If  the  search 
fails  at  any  of  the  levels,  the  optional  ERROR:  condition  is  processed. 

The  FIND  coitmand  can  be  used  in  boolean  expressions.  The  input  pointer 
position  is  altered  only  if  the  indicated  tree  was  actually  found. 
Otherwise,  the  input  pointer  remains  at  the  current  position. 


Examples : 

F I NO ( EARTH . N0N_R0TAT I N6 ) ERROR : DO ...  END 
FIND(EARTH) 

FIND((a.NON_ROTATING) 

The  above  examples  show  both  forms  of  the  FIND  statement. 

In  the  first  statement,  the  input  file  is  searched  from 
the  top  for  a first  level  node  EARTH  with  a subnode 
labeled  N0N_R0TATING.  If  not  found,  the  ERROR:  condition 
is  processed  and  the  DO  block  executed.  In  the  second 
statement,  the  search  begins  at  the  current  input  pointer 
location,  iimiediately  after  the  node  labeled  EARTH.  The 
next  level  down  is  searched  for  a node  labeled  NON  ROTATING. 


SYNTAX:  INPUT(<input  element  ><,..> 

|0R  <input  eleiiient>  <. . 

^RROR:  <statement^ 

Where<input  element>is  any  one  of  the  following:  STRINGtWORD. 
CONSTANT. NUMBER. SIGNED_NUMBER  or  <string>. 

The  INPUT  statement  allows  the  user  to  read  data  from  the  input 
file.  Reading  is  sequential  within  any  node.  The  next  term  to  be  input 
depends  upon  which  node  in  the  tree  has  been  pointed  to  and  how  many 
terms  within  that  node  have  been  previously  input.  Note  that  a FIND 
operation  always  inputs  the  first  element  of  the  node  that  it  success- 
fully finds.  This  element  is  available  to  the  user,  the  same  as  all 
elements  read  in  by  the  INPUT  command,  by  use  of  the  * notation.  (See 
Section  3.0.)  Sequential  groups  of  input  elements  may  be  requested  in 
one  INPUT  statement  simply  by  listing  them  in  the  statement  separated 
only  by  blanks.  Any  number  of  these  input  element  requests,  whether 
single  or  grouped,  may  be  combined  in  a single  INPUT  command  with  use 
of  the  optional  OR  construction.  If  the  input  file  did  not  contain  any 
one  of  the  elements  requested  in  the  preceding  input  group,  and  an  OR 
condition  is  present  in  the  input  statement,  the  input  pointer  is 
repositioned  to  the  place  it  was  when  the  INPUT  statement  was  initiated 
and  the  second  group  is  checked.  When  the  desired  input  group  is  found 
to  be  present  in  the  input  file,  the  rest  of  the  INPUT  statement  contents 
are  skipped.  If  none  of  the  requested  input  groups  are  present  in  the 
input  file  at  its  current  location,  the  input  pointer  is  left  at  a point 
following  the  last  term  requested  that  actually  was  present  in  the  input 
file.  Note  also  that  even  though  whole  groups  of  input  elements  can  be 
requested  in  one  input  command,  only  that  element  that  was  last  read  in 
is  available  for  internal  program  use  with  the  * notation. 


I 
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Normal  input  pointer  positioning  from  node  to  node  is  possible 
and  easiest  with  the  FIND  statement.  However,  it  is  possible  to  force 
the  Input  pointer  to  the  next  logical  node  in  the  input  hierarchy  with 
special  use  of  the  INPUT  conmand.  When  the  input  pointer  is  positioned 
at  the  end  of  a node,  any  further  normal  input  requests  will  fail.  The 
user  may  force  the  pointer  to  the  next  node,  regardless  of  its  level  in 
the  hierarchy,  by  issuing  the  statement  INPUT  ('END  OF  NODE').  The  special 
string  END  OF  NODE  will  force  the  pointer  to  the  next  node  only  if  the 
pointer  is  actually  positioned  after  the  last  element  on  a node  (in- 
cluding all  continuation  cards).  At  any  other  time  this  request  will 
fail.  Such  positioning  of  the  input  pointer  is  very  useful  in  instances 
where  a sequential  access  is  faster.  Note  that  positioning  of  the  pointer 
in  this  manner  will  not  automatically  input  the  first  element  of  the  next 
node  as  happens  with  the  FIND  command. 

Input  requests  are  either  by  class  of  input,  e.g.,  WORD,  NUMBER 
or  by  specific  item,  specified  in  the  form  of  a string  literal,  e.g., 

'='  or  'NAME_0F_N0DE' . Although  most  clases  of  inputs  are  self- 
explanatory,  the  distinction  between  NUMBER,  SIGNED__NUMBER  and  CONSTANT 
should  be  understood.  A request  for  NUMBER  will  only  be  successful  if  the 
next  element  is  an  unsigned  numeric  quantity,  e.g.,  7.3,  9,  4.976E+10. 
Similarly,  an  input  request  for  a SIGNED_NUMBER  will  only  succeed  if  the 
next  input  element  is  a signed  numeric  quantity,  e.g.,  +9.32,  -100.76,  -7. 
use  of  CONSTANT  permits  either  signed  or  unsigned  numeric  quantities  to 
be  input.  Under  most  circumstances,  the  use  of  CONSTANT  is  preferred. 

But  in  those  cases  in  which  signed  or  unsigned  numeric  quantities  are 
required  for  validity,  the  alternate  input  classes  provide  an  easy 
verification  check. 


The 
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Example: 


(INPUT  FILE) 


REQU I RED_A I RCRAFT_PARAMETERS 
WINGJPAN  126.3  FEET 
CRUISING_ALTITUDE  23.  THOUSAND  FEET 
CLIMB_RATE  275  FEET/SEC 
MAX  ACCELERATION  3.7  GS 


(FCF) 

P 

P 

P 

P 


DEFINE  PARAM(fl) 

SET{N=0) 

DO  FOR  EACH  SUBNODE  OF  REQUIRED_AIRCRAFT_PARAMETERS 
INPUT(WORD  NUMBER) 

ERROR:  MESSAGE( ' IS: ILLEGAL  AIRCRAFT  PARAMETER') 
INCREMENT(N) 

ENTER(PARAM(N),*) 

END 

In  this  example,  several  aircraft  parameters  are  read  in. 

The  input  file  is  assumed  to  be  structured  as  a form  filling 
exercise,  i.e.,  the  order  is  predetermined  so  that  wing 
span  is  always  the  first  item  under  REQUIRED_AIRCRAFT_ 
PARAMETERS.  The  engineer  fills  in  the  appropriate  number 
next  to  the  corresponding  identifier.  The  FCF  in  turn  reads 
each  node  by  reading  the  WORD  and  NUMBER  in  one  operation. 
The  NUMBER  is  what  is  actually  entered  into  table  PARAM 
since  it  was  the  last  item  input.  The  descriptors  at  the 
right  of  each  node  are  ignored  and  serve  only  to  give 
guidance  to  the  user  what  units  are  expected  for  the  values. 
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(INPUT  FILE) 


AREA_FORMULA 

PI*RA0IUS**2 

(FCF) 

P IF  FIND(AREA_FORMULA)  THEN  DO 
P INPUTCENO  OF  NODE')  ERROR:  DO  END 
P SET (AREA) 

P INVOKE  A_EXPR 

P END 

P A_EXPR: 

P IF  INPUT('  + ’ OR  ■ -■)  THEN  DO 
P CATENATE (0,*) 

P INVOKE  A_TERM 

P END 

P ELSE  INVOKE  AJERM 

P DO  WHILE  INPUT('+'  OR  OR  OR  '/'  OR  '**') 

P CATENATE(0,*) 

P INVOKE  A_TERM 

P END 

P END  A_EXPR 

P A_TERM: 

P IF  INPUTCC)  THEN  DO 

P CATENATE (0,*) 

P INVOKE  A_EXPR 

P INPUT(')')  ERROR:  MESSAGE(I, ■S:MISSIN6  RIGHT  PARENTHESES' 

P 'IN  ARITHMETIC  EXPRESSION') 

P CATENATE (0,*) 

P END 
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P ELSE  IF  INPUT(NUMBER)  THEN  CATENATE((a.*) 

P ELSE  DO 

P INPUT(WORD)  ERROR:  MESSAGE( I . 'S; ILLEGAL  TERM  IN', 

P ' ARITHMETIC  EXPRESSION' ) 

P CATENATE (0.*) 

P IF  INPUT('(  ')  THEN  DO 

P CATENATE (0,*) 

P INVOKE  A_EXPR 

P DO  WHILE  INPUT( ' ,' ) 

P CATENATE  (!?.*) 

P INVOKE  A_EXPR 

P END 

P INPUT(')')  ERROR:  MESSAGE(  I, 'S.-MISSING  RIGHT ', 

P ' PARENTHESIS  ON  ARRAY  DECLARATION') 

P CATENATE (0,*) 

P END 

P END 

P END  AJERM 

This  example  demonstrates  several  features  of  the 
use  of  the  INPUT  statement.  The  input  is  searched 
for  existence  of  an  AREA_FORMULA.  If  one  is  found, 
then  an  attempt  to  force  the  input  pointer  to  the 
beginning  of  the  next  node  is  made.  If  this  fails, 
i.e.,  there  are  additional  elements  at  this  node,  no 
action  is  taken.  The  FCF  assumes  that  the  formula  is 
at  the  same  node.  Then  the  symbol  AREA  in  the  default 
symbol  table  is  located.  This  is  where  the  formula 
is  to  be  stored.  See  section  3.5  for  a discussion  of 
FCF  rules.  The  rule  A_EXPR  is  invoked.  This  rule 
actually  reads  the  formula  an  element  at  a time  and 
stores  it  at  the  current  symbol  table  location,  i.e., 
AREA.  Note  that  the  INPUT  commands  used  show  how  the 


3-3‘' 


optional  OR  construct  can  be  of  invaluable  aide  in 
reading  one  of  a list  of  items  such  as  the  arithmetic 
operators.  Note  also  that  the  INPUT  command  can  be 
used  as  a boolean  expression  as  in  the  IF  and  DO  WHILE 
statements.  Lastly,  note  that  the  rules  A_EXPR  and 
A_TERM  are  recursive,  i.e.,  they  invoke  one  another. 
Such  use  of  rules  enables  a sophisticated  input 
operation  such  as  reading  an  arbitrarily  complex 
arithmetic  expression  a relatively  compact  operation. 
This  is  a sophisticated  example  and  should  be  studied 
carefully. 


NODE  EXISTS 


SYNTAX:  NOOE_EXISTS«input  tree))  [eRROR:  <statement>] 

The  N0DE_EXISTS  statement  provi-des  the  user  with  a capability  to 
test  the  input  file  for  occurrences  of  specific  inputs.  The  difference 
between  this  statement  and  the  FIND  statement  is  that  the  input  pointer 
location  is  not  altered  with  the  use  of  this  statement.  Thus,  for  example, 
it  allows  the  user  to  read  a specific  type  of  data  from  the  current  input 
file  based  upon  conditions  more  conveniently  placed  elsewhere.  Or  it  can 
be  used  to  insure  that  the  input  file  is  structured  properly  before  the  FCF 
is  processed.  This  statement  can  be  used  in  boolean  expressions  to  make 
complex  conditional  judgments. 

Example: 

P IF  NODEJXISTS (EARTH. GEOPHYSICAL)  THEN  00 
CALL  HETEST 

P CATENATE(PASS2,HEC0MM0N, ' , HEIGHT, TEMP, GEOP' ) 

P END 

In  this  example,  the  input  file  is  searched  to  see  if  the 
specified  node  exists.  If  it  does,  a call  to  the  appro- 
priate subroutine  is  placed  in  the  current  FORTRAN  output 
stream.  In  addition,  three  variable  names  are 
catenated  to  the  end  of  a value  for  symbol  HECOMMON  in  the 
PASS2  table  to  be  used  on  PASS2  substitution.  Later, 
a subroutine  named  HETEST  might  actually  be  customized 
using  the  input  data  associated  with  the  specified  node. 
This  does  not  disturb  the  current  input  processing  that 
could  be  being  used  to  directly  customize  the  current 
FORTRAN  statements. 


NODEJEXISTS(REQUIRED. INPUT)  ERROR:  MESSAGE(I ,'S:THIS  INPUT  REQUIRED') 


In  this  example,  the  NODEJEXISTS  statement  is  used  to  in- 
sure that  the  required  data  is  in  the  input  file.  If  not, 
a severe  error  message  is  issued.  Such  statements  could 
be  grouped  at  the  beginning  of  the  FCF  to  insure  the  in- 
put contained  a11  items  required  for  processing  before 
unnecessary  processing  of  the  FCF  takes  place. 


RESTORE  POINTER 


SYNTAX:  RESTORE_POINTER 

The  RESTORE_PO INTER  statement  resets  the  input  pointer  to  its  most 
recently  saved  value.  (See  SAVE_POINTER. ) 

Example: 

DO  FOR  EACH  SUBRODE  OF  AEROOYNAMIC_CALCULATIONS 
IF  INPUT  (WORD)  THEN  DO 
SET  (RULE_NAM£  * *) 

SAVE_POINTER 
INVOKE  RULE_NAME 
RESTORE_PO INTER 
END 

ELSE  MESSAGE  ('IW:  ILLEGAL  RULE  NAME’,  RULE_NAME) 

END 

In  this  example,  the  particular  aerodynamic  calculations  to  be 
performed  are  indicated  by  identifiers  that  appear  as  subnodes. 
Each  of  the  words  identifies  a rule  name.  Each  rule  is  in  turn 
invoked  in  the  order  it  appears.  Since  the  rules  that  are  invoked 
may  contain  input  parsing  operations,  the  pointer  location 
must  be  saved  and  restored  each  time  through  the  loop  to  insure 
proper  positioning  of  the  input  file  pointer. 


SAVE  POINTER 


SYNTAX:  SAVE_P0 INTER 

The  SAVE_POINTER  cormand  allows  the  user  to  save  the  current  value 
of  the  input  pointer.  The  save  is  done  as  a stack  operation. 

Example:  See  RESTORE  POINTER 
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3.4  CONDITIONAL  IF  STATEMENT 


The  use  of  conditional  constructs  provides  a powerful  aid  in  all 
programming  languages.  In  addition  to  the  special  statements  identified 
as  "TEST"  in  table  3,  the  FCF  language  provides  this  kind  of  capability 
with  the  use  of  IF... THEN  and  IF. . .THEN. . .ELSE  statements.  The  truth  or 
falsity  of  a boolean  expression  is  tested  and,  based  upon  the  result,  the 
following  FCF  code  is  processed  or  simply  scanned.  Since  there  are  no 
branch  instructions  that  physically  bypass  FCF  code,  all  code  is  checked 
for  proper  syntax.  Scanning  the  code  simply  implies  that  all  precompiler 
functions  not  related  to  syntax  checking  are  temporarily  inhibited.  The 
importance  of  this  to  the  user  is  that  all  FCF  code  whether  or  not  it  is 
executed  must  be  syntactically  correct  or  else  a severe  error  might  occur 
and  cause  an  unnecessary  (from  the  user's  viewpoint)  stoppage  in  FORTRAN 
output. 


IF  STATEMENT 

SYNTAX:  IF  <boolean  expression^  THEN  <statement>  [ELSE  <statement^ 

The  IF  statement  provides  the  foundation  for  conditional  inclusion 
of  FORTRAN  statements.  The  boolean  expression  provides  a test  which  can 
be  evaluated  as  either  true  or  false.  If  the  boolean  expression  evaluates 
to  true,  the  statement  (or  DO  block)  following  the  THEN  is  processed.  If 
the  expression  is  evaluated  as  false,  then  the  optional  ELSE  clause  is 
processed.  The  next  statement  in  sequence  following  the  IF  is  processed 
after  the  conditional  statements  have  been  executed  or  scanned  as  ap- 
propriate. 
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Example; 


IF  N>Q  OR  VALUE (A, SWITCH)  = ^ON' 

THEN  DO 

END 

ELSE  IF... THEN 

In  this  example,  the  value  for  symbol  N in  the  currently 
defined  default  symbol  table  is  tested  to  see  if  it  is 
greater  than  zero.  The  value  of  SWITCH  in  Table  A 
is  checked  to  see  if  it  is  equal  to  ON.  If  either  is 
true,  then,  the  DO  block  following  the  THEN  is  pro- 
cessed. Otherwise,  the  IF  statement  following  the 
ELSE  is  processed. 


3.5  LOOP  AND  BLOCK  STRUCTURES 


An  essential  capability  in  most  languages  is  the  ability  to 
classify  groups  of  statements  into  blocks.  These  blocks  may  simply  in- 
dicate a group  of  statements  separated  by  function,  or  a group  of  state- 
ments on  which  repetitive  actions  are  required,  or  a group  of  statements 
physically  set  apart  from  the  main  program.  In  FORTRAN,  repetitive 
blocks  are  known  as  DO  groups,  and  physically  disjoint  blocks  as  sub- 
routines or  functions. 

The  FCF  language  has  several  block  constructs.  Two  of  the  DO 
block  constructs  have  already  been  discussed:  the  DO  FOR  SYMBOL  TABLE 
block  was  discussed  with  the  symbol  table  operations;  the  DO  FOR  EACH 
SUBNODE  OF  block  was  discussed  with  input  file  operations.  The  DO  FOR 
SYMBOL  TABLE  construct  separates  a group  of  statements  for  a special  j 

operation,  namely,  to  facilitate  symbol  table  manipulations.  Similarly, 
the  DO  FOR  EACH  SUBNODE  OF  block  construct  provides  a loop  structure 
based  upon  what  appears  in  the  input  file.  Two  additional  block  con- 
structs and  a loop  construct  are  discussed  here. 

In  addition  to  the  loop  and  block  statements  discussed  below, 
groups  of  FCF  statements  can  be  blocked  together  to  form  what  is  known 
as  a rule.  A rule  is  a block  construct  that  can  be  accessed  via  the 
INVOKE  statement  discussed  below.  A rule  is  roughly  similar  to  a sub- 
routine in  FORTRAN  with  the  INVOKE  similar  to  a FORTRAN  call  statement. 

There  are,  however,  no  arguments  associated  with  a new  rule  or  an  INVOKE 
statement.  Since  all  FLTOPS  variables  are  global  in  scope,  all  rules 
have  access  to  all  variables. 

! 

ij 

v’ 
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SIMPLE  00 

SYNTAX:  DO 

END 


The  simple  DO  statement  provides  a convenient  way  to  block  functional 
parts  of  the  FCF.  It  also  provides  a way  of  performing  a number  of  state- 
ments when  a test  has  failed  as  in  ERROR:  conditions  or  as  options  in  an  IF 
construct. 


Examp  1 e : 

IF  N>0 
THEN  00 

END 

In  this  example,  the  entire  00  block  is  processed  if  and 
only  if  the  value  for  N in  the  currently  defined  default 
symbol  table  is  greater  than  zero. 


DO  WHILE 


1 

1 


I I 

SYNTAX:  DO  WHILE  ^boolean  expr8SSion> 

END 

The  DO  WHILE  block  allows  for  repetitive  processing  of  a block  of 
statements  while  a boolean  expression  evaluates  to  true.  If  the  expression 
were  false,  then  the  block  would  not  be  processed. 


Example: 

SETOD 

DO  WHILE  I<=VALUE (CONSTANT, N) 
INPUT(CONSTANT) 
ENTER(A(I),*) 

INCREMENT(I) 

END 


In  this  example,  N values  are  read  from  input  and  stored 
in  Table  A.  The  test  of  I and  VALUE ( CONSTANT, N)  is  made 
before  each  pass  through  the  loop.  Once  I becomes  larger 
than  the  value  of  N,  the  loop  is  terminated.  As  in  all 
loop  constructs,  care  must  be  taken  to  avoid  conditions 
which  would  preclude  loop  termination. 


■ 

I 
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INVOKE 


SYNTAX:  INVOKE  < string  express! on> 

The  INVOKE  statement  performs  the  function  of  logically  inserting 
an  entire  FCF  rule  of  the  specified  name  at  the  point  of  the  INVOKE  state- 
ment. The  named  rule  is  processed  and  then  control  transferred  back  to  the 
calling  FCF  rule.  A rule  is  a block  of  FCF  code  that  begins  with  a rule 
name,  followed  by  a : . Each  rule  must  be  terminated  with  an  end  statement 
bearing  the  name  of  the  rule.  Rule  names  are  normally  words. 

Example: 

IF  NEWRULE  = '6SUBR' 

THEN  INVOKE  GSUBR 


GSUBR: 

*.  Legal  FCF  Language  and  FORTRAN  statements 
END  GSUBR 

In  this  example,  if  the  value  of  symbol  NEWRULE  in  the 
default  symbol  table  is  GSUBR,  then  a rule  by  that  same 
name  is  processed.  The  rule  is  terminated  properly  with 
an  END  statement  bearing  the  rule  name. 


3.6  OUTPUT/MESSAGES 


The  FLTOPS  precompiler  automatically  writes  out  any  statements  whose 
first  character  is  not  a P that  it  encounters  while  operating  with  its 
FUNCTION  switch  set  to  FULL  (see  Section  3.10).  However,  it  may  often  be 
desirable  for  a FCF  writer  to  synthesize  FORTRAN  statements  based  upon  user 
inputs  or  precompile  time  computations.  Such  specialized  output  capability 
is  provided  via  the  OUTPUT  statement.  Additional  output  capability  is  pro- 
vided to  the  user  through  the  MESSAGE  statement  which  provides  the  FCF  writer 
with  a generalized  capability  to  write  out  information  to  be  printed. 


OUTPUT 


SYNTAX;  0UTPUT{< output  element>[,<. . .>]) 

where  <output  element>  can  be  any  one  of  the  following: 
<value>  £<format>] 

or  $<number>  (identifies  a label) 
or  # (statement  terminator  symbol) 

or  C:  (indicates  start  of  a FORTRAN 

COMMENT:  comment  card) 

or  COL«arithmetic  expression^)  (indicates  which  column 
COLUMN « arithmetic  expression>)  start  with) 

or  EOF  (indicates  an  end  of  file  mark  to 

END_OF_FILE  be  output) 

or  EOR  (indicates  an  end  of  record  mark 

END  OF  RECORD  to  be  output) 


The  OUTPUT  statement  provides  FCF  writers  the  capability  to 
synthesize  FORTRAN  statements  based  upon  specific  user  inputs.  Since 
no  syntax  checking  is  done  on  FORTRAN  statements  prior  to  FORTRAN 
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compilation,  the  user  should  take  care  that  statements  so  synthesized  are 
syntactically  correct.  Labels  can  be  generated  by  use  of  the  special 
label  feature  (see  above).  These  labels  are  uniquely  generated  numbers 
produced  automatically  by  the  precompiler  from  a user  assigned  base  value 
(see  LBLNUM  in  Section  3.9).  All  output  is  gathered  in  a buffer  until 
the  user  explicitly  outputs  the  statement  terminator  character  (#).  At 
that  time,  the  synthesized  FORTRAN  is  output  to  the  FORTRAN  file. Continua- 
tion cards  and  statement  sequence  numbers  are  provided  as  appropriate  for 
all  FORTRAN  statements. 

FCF  users  are  also  able  to  synthesize  their  own  FORTRAN  comment 
cards.  By  explicitly  entering  C:  or  COMMENT:  as  an  output  element,  the 
FCF  indicates  to  the  precompiler  that  a comment  card  is  being  generated. 
Either  a C or  COMMENT  is  placed  in  the  output  buffer  beginning  in 
character  position  1.  Any  output  elements  can  follow  the  comment 
designator  as  in  normal  output  operations.  Upon  receipt  of  the  statement 
terminator  the  contents  of  the  output  buffer  are  output  as  a FORTRAN 
comment  card. 

The  FCF  user  also  can  output  end  of  file  and  end  of  record  marks 
as  befits  his  situation.  These  are  output  as  they  occur.  If  the  output 
buffer  is  not  emply,  i.e.,  previous  output  element  was  not  a statement 
terminator,  this  EOF  or  EOR  mark  also  acts  as  the  statement  terminator. 

The  FCF  user  also  has  at  his  disposal  some  degree  of  format  control 
of  the  output.  As  in  symbol  table  operations,  any  value  output  can  be 
formated  to  the  user  specifications  before  entry  into  the  output  buffer. 
This  is  especially  handy  in  the  DATA  output  mode  in  which  numbers  of 
particular  accuracy  are  required.  Any  FORTRAN  formats  are  legal  as  per 
implementation  option.  In  addition  the  OUTPUT  statements  also  allows 
the  user  to  specify  the  column,  i.e.,  character  position,  in  which  the 
next  output  element  is  to  be  placed.  If  the  column  specified  is  already 
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occupied,  the  precompiler  outputs  a warning  message,  then  a statement 
terminator  command  is  implicitly  issued  emptying  the  current  output 
buffer  contents.  At  this  point  the  output  buffer  is  padded  with  blanks 
to  the  desired  column.  Note,  the  next  element  output  starts  in  the 
column  identified  by  the  COL  command. 

Example: 

0UTPUT($1,  'DO  ',  $2,  ■ 1=1,') 

. No  FORTRAN  statements  should 

appear  here. 

OUTPUT(VALUE(N) ,#)  Any  FORTRAN  appearing  here  will 

^ be  included  in  the  DO  block 


0UTPUT($2, 'CONTINUE',#) 

In  this  example,  the  following  synthesized  FORTRAN  state- 
ments are  written  out.  The  labels  generated  do  not 
necessarily  correspond  to  what  would  be  generated  in  an 
actual  implementation. 

99001  DO  99002  1=1,100,2 


99002  CONTINUE 

Here,  it  is  assumed  the  value  of  N is  100,2. 

0UTPUT(C:,  COL(ll),  RULE-NAME, 

'WAS  THE  FCF  RULE  THAT  GENERATED  THIS  CODE',  #) 


SET (OUTPUT* 'DATA') 

0UTPUT(C0L(7),  'DATA',  NAME  =>  A6,  '/',  #) 


SET  (CARD_COUNT  = 1) 

DO  WHILE  CARDj:OUNT<=  MAX_CARDS 
SET  (N=l) 

OUTPUT  (COL (6),  CARD  COUNT  =>  II) 

DO  WHILE  N<=  6 

OUTPUT  (DATAJ/ALUES  (N,  CARD_COUNT)  =>  F8.3) 

IF  N * 6 AND  CARD_COUNT  = MAX .CARDS  THEN 
OUTPUT  (V) 

ELSE  OUTPUT  ( ' , ' ) 

END 

OUTPUT  (#) 

END 

SET  (OUTPUT  = 'FORTRAN') 

This  example  shows  several  features  of  the  output  command. 

Initially  a FORTRAN  coiment  card  is  output  which  indicates  which  rule 
is  outputing  the  following  data.  Next  the  OUTPUT  switch  is  set  to  DATA 
and  a DATA  card  is  written.  In  the  DATA  mode,  output  is  not  reformatted 
to  conform  to  any  special  card-image  format.  Special  format  conventions 
that  may  be  needed  by  output  generated  in  this  mode  are  controlled 
entirely  by  the  user.  The  NAME  of  the  array  for  the  data  is  output 
next.  Note  that  it  is  constrained  to  six  characters  by  the  format 
A6.  Next  the  correct  number  of  cards  are  output  containing  the  continuation 
indicator  in  column  6 and  six  data  values  in  F8.3  format  per  card.  Except 
for  the  last  element  or  the  last  card,  a comma  follows  the  value.  After 
the  data  has  been  output,  the  OUTPUT  switch  is  set  bacK  te  FORTRAN. 


MESSAGE 


SYNTAX:  MESSAGE  (<value>  [ <format>)  [,<  ...>]  ) 

The  message  statement  allows  the  FCF  writer  to  output  error  and 
informational  messages  to  the  run  time  output  file  for  use  by  those 
executing  the  FCF.  The  message  can  be  made  up  of  any  number  of  symbol 
table  entries  or  calculated  values,  as  long  as  the  first  three  characters 
of  the  message  conform  to  the  following  syntax: 

TYPE  SEVERITY-LEVEL:  Text  of  Message 

The  first  character  of  the  message  must  be  either  an  I for  input  file 
errors  or  G for  miscellaneous  message  types.  The  severity  level  is  a 
single  character  that  identifies  the  level  of  error  printed.  It  can 
be  any  one  of  the  following: 

Here  severity  level  can  be 

F - Fatal  error  — all  FCF  processing  stops.  This  level 
of  error  is  not  normally  set  by  FCF  builders  as  it 
constitutes  an  immediate  stop  to  all  processing. 

It  is,  however,  issued  by  the  precompiler  for  various  in- 
ternally inconsistent  problems. 

S - Severe  error  — output  of  FORTRAN  statements  ceases,  but 
continues  to  parse  the  FCF  and  check  for  further  errors. 

For  input  errors,  the  input  file  will  continue  to  be  read 
although  FORTRAN  output  ceases. 

W - Warning  error  — does  not  affect  processing  of  the  FCF, 
but  some  likelihood  of  it  being  an  unintentional  error. 

N - A note  — a'  message  indicationg  some  point  of  docu- 
mentary interest  to  the  user  and/or  FCF  builder. 


3-49 


The  third  character  position  In  the  message  Is  Ignored.  It 
should  be  either,  a colon  (:)  or  blank  for  readability,  hovi«ver. 

Type  general  messages  are  output  Immediately,  whereas  type  Input 
messages  are  saved  and  printed  out  at  the  appropriate  point  In 
the  Input  file. 

Any  symbol  table  entry  can  be  output  with  the  MESSAGE  command 
as  well  as  Internal  computations.  Successive  elements  are  simply 
catenated  to  the  end  of  the  message  until  the  closing  parenthesis  of 
the  statement  Is  encountered.  At  that  point  the  appropriate  message 
action  Is  taken.  Note  that  as  In  the  OUTPUT  statement,  the  elements 
output  are  under  user  specified  format  control. 

Example: 

MESSAGE  ('GS:  THIS  IS  ONE  WAY  MESSAGES  ARE  WRITTEN’) 

A severe  general  type  message  Is  written  to  the  output  listing. 
The  severe  error  Is  printed  Immediately  and  Inhibits  further 
processing  of  the  FCF  that  Is  not  purely  syntactic. 

MESSAGE  ('IW:  A WARNING  MESSAGE  FOR  AN  INPUT  ERROR') 

An  Input  warning  type  message  Is  written.  This  message  will 
appear  In  the  Input  file  listing  at  the  position  It  occured. 

MESSAGE  ('GN:  THE  VALUE  OF  A,  B,  C - ’ ,A  ■ >F8.3, 

B * >F9.4,  C-M51 

The  message  statement  outputs  the  values  of  various  s>mboi 
table  entries  in  the  specified  formats.  Since  this  is  a 
note  level  message,  it  is  not  written  unless  the  NOTES  switch 
Is  set  to  ON. 


3.7  COMPUTING  PRECOMPILE  TIME  VALUES 

To  allow  the  FCF  builder  to  incorporate  values  that  are  determinable 
at  precompile  time,  two  statements  are  provided.  Any  parameters  that  depend 
upon  aircraft  test  data  are  obviously  not  determinable  at  precompile  time. 
However,  this  capability  is  useful  for  determining  parameters  derivable  from 
aircraft  constants,  standard  atmosphere,  or  geopotential  model  parameters, 
etc.  Two  statements  are  used.  The  PARAMETERS  statement  identifies  the  type 
and  quantity  of  data  to  be  supplied  to  the  execute  module.  The  EXECUTE  state- 
ment actually  transfers  the  control  to  the  desired  routine  and  passes/returns 
the  correct  data. 

Data  Considerations 

To  compute  precompile  time  values  requires  some  data  considera- 
tions. Data  that  are  essentially  strings  must  be  converted  to  equivalent 
internal  values  to  be  used  by  the  executing  routine,  and  they  must  be  stored 
in  a common  area  that  can  be  accessed  both  by  the  precoirpiler  and  the  routine 
doing  the  computations.  To  provide  the  proper  data  communications,  two 
separate  requirements  are  identified:  an  execute-environment- table  and  an 
execute-data-area . 

The  execute-environment-table  contains  information  necessary  for 
the  proper  conversion  and  passing  of  data  to  the  executing  routine.  This 
table  contains  the  following  information  for  each  parameter  value(s)  that 
is  to  be  passed  to  the  executing  program. 

1)  What  type  of  data  — i.e.,  REAL,  INTEGER,  ALPHA,  LOGICAL,  DOUBLE. 

2)  How  much  data  — i.e.,  how  many  data  values  of  the  identified 
type  for  this  parameter  are  required  in  the  executing  program. 

3)  Where  is  the  data  found  — i.e.,  a precompiler  unique  internal 
data  address  where  the  requested  data  can  be  found  or  stored. 

A different  environment  table  is  maintained  for  each  routine  that 
can  be  used  to  compute  precompile  time  values.  A simple,  but  not  neces- 
sary, way  of  thinking  of  this  table  is  as  a matrix  in  which  the  i^^  row 
contains  the  above  three  items  of  Information  for  the  i^"  parameter  data 
address . 
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The  execute-data-area  contains  the  data  that  will  be  processed 
and/or  returned  by  the  executing  program.  It  is  in  internally-usable 
format  and  is  saved  in  the  execute-data-area  sequentially  in  the  same 
order  that  the  parameters  appeared  when  the  routine  was  called.  Figure 
6 shows  the  data  conmunication  between  the  precompiler  and  an  executing 
routine. 


User  interface  with  these  tables  is  provided  through  two  state- 
ments whose  form  and  syntax  is  provided  below. 


PARAMETERS 


SYNTAX:  PARAMETERS  <execate  .routine>  (< parameter > < parameter)  <...>]) 

The  PARAMETERS  statement  identifies  the  type  and  amount  of  data 
required  by  the  routine  to  be  executed»>  The  < execute  routine)  is  any 
legal  <worc^.  . Here  a valid<paratneter>is  anyone  of  the  following; 

REAL  [(subscripts]^ 

INTEGER[<subscripts>l 
LOGIC Al[< subs crip  ts>J 
DOUBLE  [(subscripts)] 

ALPHA  [(subscripts]^ 

Only  the  above  five  descriptors  followed  by  optional  subscripts  are  valid  i"^ 
the  parameter  list.  As  many  parameters  must  be  defined  here  as  there  are 
arguments  in  the  calling  sequence  of  the  routine  to  be  executed. 


Example: 


See  EXECUTE 


Execute  Date  Area 


Figure  6.  Data 'Communications  Between  the  Precompiler  and  the  Execute  Routine 


EXECUTE 


SYNTAX:  EXECUTE  <execute  routine>  (<  argument > [^,  <argunient>  <...  >1) 
where  <ar9ument>is  either  ^arithmetic  expression>or  <strin^ 

The  EXECUTE  statement  initiates  the  activity  which  causes  the  precom- 
pile time  values  to  be  calculated  from  the  supplied  data.  The  EXECUTE  rou- 
tine, identified  by  any  legal  <word>  , calculates  values  with  data  supplied 
as  arguments. 

The  argument  identifies  which  data  is  to  be  used  in  the  calculations 
whereas  the  PARAMETERS  statement  identifies  what  kind  and  how  much  data. 

Example: 

PARAMETERS  SUBR(INTEGER,REAL(N) ,R£AL) 

EXECUTE  SUBR(N,A(1),VALUE(X,Y)) 

In  this  example,  a routine  named  SUBR  is  to  be  used  to 
calculate  some  value(s).  Three  arguments  are  identified. 
The  first  is  to  be  treated  as  an  integer,  the  other  two 
as  floating  point  numbers.  The  second  is  to  have  more  than 
one  real  value,  the  exact  number  determined  by  the  current 
value  for  symbol  N in  the  default  symbol  table.  The  actual 
values  passed/ returned  are  determined  by  the  EXECUTE 
arguments.  The  integer  is  to  be  found  as  the  value  for  N 
in  the  default  symbol  table.  The  multiple  real  values  are 
to  be  found  star-ting  at  subscript  pcsitiof«  1 .n  Table  t 
The  final  real  value  will  be  found  at  symbol  Y in  Table 
X.  Since  no  argument  is  labeled  as  an  input  or  as  an  out- 
put,  all  values  are  treated  identically.  It  is  up  to  the 
user  to  insure  that  needed  information  is  not  destroyed 
by  the  executing  routine. 
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3.8  BUILT-IN  FUNCTIONS 


The  FLTOPS  precompiler  contains  several  built-in  functions  usable 
by  the  FCF  writer  to  provide  enhanced  flexibility  in  symbol  table  access 
and  string  manipulation.  These  built-in  functions  are  not  usable  by 
themselves  but  only  in  combination  with  any  legal  FCF  statement.  The 
INDEX,  LENGTH,  and  SUBSTRING  functions  provide  the  FCF  users  with  the 
same  specialized  string  manipulation  features  as  are  available  in  other 
progratiming  languages.  The  VALUE  function  is  unique  to  FLTOPS  and  enables 
the  user  to  directly  reference  any  symbol  table  entry. 


INDEX  FUNCTION 


SYNTAX:  INDEX  «string  expression>,  <string  expression» 

The  INDEX  function  returns  the  starting  location  of  the  substring 
identified  by  the  second  <string  expressior)  within  the  string  identified 
by  the  first  <string  expression>.  If  the  second  string  is  not  a sub- 
string of  the  first  string  a value  of  0 (zero)  is  returned. 

Example: 

IF  INDEX  ('**+-/ ',*)>0  THEN 
D0_ 

END 

In  this  example  the  last  element  read  from  input  is  checked  to 
see  if  it  is  one  of  the  arithmetic  operators.  If  it  is,  then 
some  additional  FCF  statements  will  be  processed. 
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SET  (N  = INDEX  (ALPHABET,  SUBSTRING  (*,  1,  1)  ) ) 


In  this  example  the  symbol  N in  the  default  symbol  table  is 
set  to  the  number  of  the  letter  of  the  alphabet  (stored  in 
symbol  location  ALPHABET)  with  which  the  first  character  of 
the  last  element  input  begins.  If  it  does  not  start  with  an 
alphabetic  character  N will  be  set  to  zero. 


LENGTH  FUNCTION 


SYNTAX:  LENGTH  «string  expression» 

The  LENGTH  function  returns  the  integer  number  of  characters  that 
comprise  the  indicated  <string  expression^.  If  the  string  is  null  (i.e. 
empty)  the  value  returned  is  zero. 

Example: 

SET  (N  = LENGTH  ( ’ABODE ’)  ) 

The  value  of  N is  set  to  5. 

SET  (N  = LENGTH  (*)  ) 

The  value  of  N is  set  to  the  number  of  characters  contained  in 
the  element  last  read  ^rom  the  input  file. 

IF  LENGTH  (ALPHABET)<26  THEN  MESSAGE  ('GW;  NOT  ALL  LETTERS  PROVIDED 
IN  THE  ALPHABET  TABLE  ENTRY') 

In  this  example,  the  symbol  ALPHABET  in  the  default  symbol  table 
is  checked  to  see  if  it  contains  enough  characters  for  the  whole 
alphabet. 
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SUBSTRING  FUNCTION 


SYNTAX:  SUBSTRING  «string  expression>,  <start  pos1t1on>Q<length>]) 

The  SUBSTRING  function  enables  users  to  obtain  a substring  of  a 
given  <string  expression^.  The  substring  is  created  by  starting  at  the 
character  position  identified  by  the  parameter  <start  position>,  which 
can  be  any  ^arithmetic  expression>.  A maximum  of  <length>  characters 
starting  with^start  positioii^  comprise  the  substring.  If  less  than 
<length^  characters  are  actually  available,  the  substring  is  padded  with 
blanks  to  achieve  the  desired  length.  The  parameter  <length>  can  be  any 
^arithmetic  expression^.  If  the  <length^  is  not  given,  the  substring 
contains  all  characters  including  and  to  the  right  of  position  ^start 
position^  in  ^string  expression^.  If  <length>  is  zero,  the  substring  is 
null.  The  SUBSTRING  function  is  not  legal  by  itself  as  an  FCF  control 
statement.  It  is  only  legal  within  the  context  of  other  FCF  language 
statements. 

Example: 

SET  (NAME  = SUBSTRING  (*,  1,6)) 

ENTER  (A,  B,  SUBSTRING  (VALUE  (A,  TEMP),  7,10)) 

SET  (OPERATOR  =•  SUBSTRING  ('+-/**',  N,  VALUE  (A,  LENGTH)  ) ) 

SET  (OPERATOR  =■  SUBSTRING  (’+-/**'.  A)  ) 

In  these  examples  the  SUBSTRING  function  is  being  used  to 
enter  portions  of  a predefined  string  into  a symbol  table. 

In  the  first  example,  the  last  data  read  from  input  has  its 
first  six  characters  being  stored  as  the  value  for  symbol 
NAME  in  the  default  symbol  table.  In  the  second,  a 10 
character  substring  starting  at  character  position  7 is 
being  extracted  from  symbol  entry  TEMP  in  table  A. 

This  substring  will  be  stored  as  symbol 
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T in  Table  A.  In  the  third  example,  a s^inbol  named  OPERATOR 

v/ill  liavc  its  value  be  dctorriined  by  a substring  created  from 

the  given  string  literal.  The  substring  will  start  in  the  • 

position  indicated  by  the  value  of  symbol  N and  be  of  length 

determined  by  the  value  of  symbol  LENGTH.  In  the  last  example, 

OPERATOR  is  set  to  the  substring  **,  which  includes  all 
characters  to  the  right  of  and  including  position  4 in  the 
original  string. 


VALUE  FUNCTION 


SYNTAX;  VALUE  « table  name>,  < symbol  name» 
or  VALUE  « table  name><subscripts» 
or  VALUE  « symbol  name>) 
or  VALUE  (0) 

The  VALUE  FUNCTION  retrieves  symbol  table  entries  and  makes  them 
available  to  the  user.  The  VALUE  function  is  not  legal  by  itself  as  an 
FCF  language  instruction.  It  is  only  legal  within  the  context  of  other 
FCF  language  statements.  The  four  forms  retrieve  values  from  the  specified 
locations.  The  first  two  retrieve  the  value  associated  with  the  indicated 
table  and  symbol  name  or  subscript  respectively.  The  third  retrieves  the 
value  associated  with  the  symbol  named  in  the  currently  defined  default 
symbol  table.  The  last  retrieves  the  value  associated  with  the  current 
location  of  the  symbol  table  pointer. 

Example: 

IF  VALUE(A,I)>0  THEN  . . . 

SET(Z-VALUE(X(VALUE(A,I)))) 

ENTER(A,B,VALUE{N)) 

This  example  shows  how  the  first  three  forms  of  the  value  function 
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might  appear.  Note  that  in  the  second  statement,  VALUE  functions  can 
be  nested.  This  can  be  a valuable  aid  in  actual  practice. 

ENTER  (A.B.'N') 

SET  (VALUE  (@)  = 7) 

In  this  use  of  the  VALUE  function,  the  value  is  retrieved  from  the 
most  recent  placement  of  the  symbol  table  pointer.  Assuming  no  intermediate 
placements  of  the  symbol  table  pointer,  the  symbol  N is  retrieved  from 
table  A,  symbol  B.  N is  assumed  to  be  a symbol  name  in  the  current 
default  symbol  task  and  is  assigned  the  value  of  7. 
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3.9  DEBUGGING  AIDS 


Two  debugging  aids  are  provided  tn  the  form  of  statements  to  be  used 
by  the  FCF  writer.  The  ASSERT  and  STATUS  commands  are  executed  only  if  the 
DEBUG  switch  Csee  Section  3.10) is  set  to  ON.  Otherwise,  they  are  ignored. 
Initially,  the  DEBUG  switch  is  set  to  OFF.  The  user  also  has  access  to  a 
TRACE  feature  described  in  detail  in  Section  3.10. 


ASSERT 


SYNTAX:  ASSERT  ^boolean  expression>  [ERROR:  <statement>J 

The  ASSERT  statement  allows  the  user  to  test  various  conditions  at 
different  stages  of  FCF  processing.  In  this  way,  he  can  monitor  progress 
and  perhaps  determine  where  or  why  certain  run  time  errors  or  undesired  output 
are  happening.  If  the  boolean  e.xpression  is  false,  the  optional  ERROR: 
condition  is  processed.  If  not  present,  a default  error  message  is  written 
by  the  precompiler.  No  action  is  taken  if  the  assertion  proves  to  be  true. 

Examp  1 e : 

ASSERT  VALUECA,X)»' FALSE'  AND  SWITCH='0N' 

ERROR:  DO 

END 

In  this  example,  the  various  values  are  checked  to  see 
if  the  relation  holds.  If  either  one  is  not  true,  the 
optional  DO... END  block  is  processed. 
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STATUS 


SYNTAX:  STATUS  C<string» 

or  STATUS {<string>,  <table  name>) 
or  STATUS«string>,  <table  name>,  <symbol  name» 
or  STATUS Kstring>,  <table  name>  <subscripts» 


The  STATUS  statement  writes  out  a comment  string  and  the  contents 
of  various  tables/symbols  depending  on  the  form  of  the  statement.  If  just 
a comment  string  appears  in  the  argument  list,  the  comment  string  and  a com- 
plete status  of  the  precompiler  is  written  which  includes  the  contents  of 
all  symbol  tables.  If  the  second  form  above  is  used,  then  the  entire  con- 
tents of  the  table  name  specified  are  written  out  along  with  the  comment 
string.  In  the  last  two  forms  above,  the  individual  symbol  table  value  is 
written  out  in  addition  to  the  comment  string.  In  all  cases,  table  names, 
symbol  names  or  subscripts  are  appropriately  labeled  on  output  for  easy 
comprehension. 


Example: 

STATUS ('DUMP  OF  ALL  TABLES') 

STATUS( 'TABLE  A CONTENTS',  A) 

STATUS ('SYMBOL  X IN  TABLE  A',  A,X) 

STATUS ('VALUE  IN  TABLE  TAB',  TAB(3)) 

The  above  examples  demonstrate  each  form  of  the  STATUS 
statement.  The  TRACE  feature  operates  separately  from 
the  above  STATUS  statements. 
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3.10  SWITCHES  AND  COUNTERS 


An  important  functional  part  of  the  FCF  control  language  Is  the 
existence  of  a number  of  switches  and  counters  that  are  made  available  to 
the  user.  By  setting  these  switches  and  counters,  the  FCF  writer  can  con- 
trol basic  functions  of  the  precompiler  without  special  instructions  or 
language  forms.  Each  swi tch/counter  is  identified  as  a symbol  entry  in  the 
FLTOPS  symbol  table.  Since  they  are  normal  symbol  table  entries,  they  can 
be  accessed  using  any  of  the  symbol  table  operations  discussed  in  Section 
3.2  Note,  however,  use  of  the  DELETE  or  CLEAR_TABLE  statements  will  not 
affect  any  of  the  switches  and  counters  defined  here.  Table  3 presents  a 
simplified  summary  of  the  switches/counters  discussed  below. 


ALPHA/ INTEGER/LOGICAL/REAL 


Each  of  the  above  switches  controls  data  conversion  for  those 
values  used  In  an  EXECUTE  route.  If  the  switch  is  left  at  the  default  value 
of  null,  the  precompiler  will  use  predefined  rules  established  at  implemen- 
tation time  to  convert  the  values  for  each  type.  The  exact  nature  of  these 
rules  is  left  to  the  implementor.  If  the  switches  are  set  to  other  than 
null,  then  the  corresponding  data  types  will  be  converted  accordingly  to 
the  exact  specification  given.  The  setting  of  these  switches  to  null  will 
actually  result  in  the  respective  default  value  being  inserted  in  the  symbol 
table. 

Example: 

PARAMETERS  SUBR (REAL ( 5 ) , INTEGER , REAL ) 

SETCREAL='F10.4‘) 

EXECUTE  SUBR(A(1),5,VALUE(Y.X)) 

In  this  example,  upon  completion  of  the  execute,  the 
values  identified  as  REAL  will  be  stored  in  the  symbol 
table  locations  as  strings  using  an  F10.4  conversion 
format.  The  integer  will  be  converted  using  a prede- 
fined precompiler  default  procedure. 
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TABLE  4. 


SWITCHES/ COUNTERS  SUMMARY 


riTiPs 

SYMBOL 

VALUES 

SIGNIFICANCE 

ALPHA 

null , or  legal 
FORTRAN  A format 

Controls  conversion  of  string  data  used 
with  the  EXECUTE  statement 

Default  • Implementation  option 

DEBUG 

ON.  OFF 

Controls  execution  of  STATUS  and  ASSERT 
statements 

Default  - off 

FUNCTION 

FULL.  TEST. 

SYNTAX 

Controls  precompiler  operation  Including 
generation  of  FORTRAN  output 

Default  - full 

INTEGER 

null,  or  legal 
FORTRAN  I format 

Controls  conversion  of  integer  values  usee 
with  the  EXECUTE  statement 

Default  • Implementation  option 

LBLNUM 

any  number 

0 - 99999 

Number  of  first  label  to  be  used  for 
automatically  generated  labels 

Default  - 99000 

LENGTH 

OFF  or  any 
number 

Counter  contains  estimate  of  storage  re- 
quirements of  FORTRAN  output 

Default  - OFF 

LOGICAL 

null . or  any  legal 
FORTRAN  L format 

Controls  conversion  of  logical  values 
used  with  the  execute  statement 

Default  - iiiipleHientation  option 

NOTES 

ON,  OFF 

Controls  printing  of  messages  at  "NOTES" 
level  of  severity 

Default  - OFF 

OUTPUT 

FORTRAN 
or  DATA 

Controls  the  kind  of  format  used  when 
processing  PASS  1 and  PASS  2 output 
files.  Default  . FORTRAN 

REAL 

null  or  any  legal 
FORTRAN  P.  G.  £. 
or  0 format 

Controls  conversion  of  floating  point 
numbers  used  with  Che  EXECUTE  statement 
Default  - Implementation  option 

STATS 

ON.  OFF 

Controls  collection  and  printing  of 
statistical  Information  on  run. 

Default  - OFF 

TRACE 

OFF,  LOW,  HIGH 

Controls  generation  of  TRACE  debugging 
Information  on  run 

Default  - OFF 

XREF 

ON,  OFF 

Controls  generation  of  cross  reference 
map  of  symbol  table  usage. 

Default  - OFF 
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DEBUG 


The  DEBUG  flag  allows  users  to  selectively  process  ASSERT  and 
STATUS  statements.  It  may  be  turned  on  or  off  at  any  time.  As  a result, 
users  may  leave  these  debugging  aids  in  the  FCF  at  all  times  and  selectively 
or  collectively  execute  them. 

Example; 

ENTER CFLTOPS. DEBUG, 'ON') 

• • 

ASSERT  VALUE  (A,B)  = 'OFF' 

ERROR:  DO 

MESSAGE  ('GW:  SWITCH  B,  TABLE  A FORCED  TO  OFF  POSITION') 
ENTER  (A.B,  'OFF') 

END 

IF  VALUE  (A.B)  * 'OFF'  THEN  ENTER  (FLTOPS,  DEBUG ."^FF^) 

STATUS  ( 'FLTOPS  SYMBOL  TABLE',  FLTOPS) 

In  this  example  the  ASSERT  conmand  will  be 
executed  since  the  DEBUG  switch  is  on.  The 
STATUS  command  however  will  not  be  executed 
since  the  DEBUG  switch  was  turned  off. 


FUNCTION 


Access  to  the  FUNCTION  switch  provides  the  FCF  user  with  control  over 
basic  precompiler  operation.  By  setting  the  switch  to  one  of  three  user 
assignable  values,  the  user  can  control  the  processing  of  the  FCF.  Each 
setting  is  described  in  more  detail  below. 

FULL;  The  default  setting  of  this  switch  indicates  that  the 

precompiler's  functions  are  all  operational.  The  FCF  is 
processed,  the  input  file  can  be  read,  and  FORTRAN  output 
generated. 
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TEST;  By  setting  the  switch  to  this  value,  the  user  Inhibits  all 
FORTRAN  output.  Otherwise,  normal  FCF  processing  occurs 
and  the  input  file  can  be  read. 

SYNTAX:  By  setting  the  switch  to  this  value,  the  user  inhibits  all 
FCF  processing  except  basic  syntax  checking.  As  a result, 
once  set  to  this  value,  the  FUNCTION  switch  cannot  be  reset 
to  another  value. 

Example: 

SET CFUNCTION- ‘TEST') 

In  this  example,  no  FORTRAN  output  will  be  generated 
from  this  statement  on.  The  FCF  will  be  executed 
and  input  read,  however. 


LBLNUM 


The  precompiler  will  generate  labels  for  synthesized  FORTRAN  state- 
ments using  the  number  appearing  in  LBLNUM  as  its  base.  LBLNUM  can  be  re- 
set anywhere  without  effect  on  already  generated  labels. 

Example: 

SET CLBLNUM« 1000) 

OUTPUTC'GO  TO  ' ,$1) 

SETCLBLNUM«2000) 

0UTPUT($1,' CONTINUE') 

In  this  example,  1000  is  already  associated  by  the  pre- 
compiler with  $1,  so  that  resetting  LBLNUM  has  no 
effect  on  already  assigned  labels. 
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LENGTH 


LENGTH  is  a counter  that  can  be  used  to  estimate  the  amount  of 
core  that  will  be  used  by  the  FORTRAN  code  being  output.  If  set  to  a num- 
ber, the  FORTRAN  lexical  analyzer  will  increment  the  counter  by  a fixed 
amount  for  each  different  token  it  processes.  When  reset  to  its  default 
value  of  OFF,  the  lexical  analyzer  no  longer  increments  the  counter.  The 
user  can  increment  the  counter  himself  to  account  for  commons  and  dimensioned 
values  not  counted  by  the  lexical  analyzer.  The  actual  amount  that  each 
token  will  increment  the  counter  is  dependent  upon  the  particular  machine 
on  which  the  code  is  to  be  run  and  can  be  at  best  a good  guess. 

Example: 

P 

P 

P 
P 
P 

In  this  example,  the  LENGTH  counter  is  assumed  to  have 
been  turned  on  in  an  earlier  step.  The  first  SET 
instruction  increments  the  counter  by  the  value  of 
C0MM0NJ.CNGTH,  which  contains  the  total  length  cf 
associated  coumons.  LENGTH  is  later  tested  to  deter- 
mine if  it  exceeds  a core  length  requirement.  If  it 
does,  then  the  overlay  card  is  inserted,  the  length 
reset  to  zero,  and  a flag  set  in  the  table  OVERLAY 
to  indicate  which  overlay  had  been  called  for  pos- 
sible later  use. 


SET (LENGTH=LENGTH+V ALUE (C0MM0N_LEN6TH ) ) 

IF  LENGTH>45000  THEN  DO 
CALL  0VLY(4HSUBR,1,1) 

SET(LENGTH=0) 

ENTER (OVERLAY ,SUBR11 , ‘TRUE ' ) 

END 


NOTES,  STATS,  TRACE,  XREF 


Each  of  the  above  on/off  switches  controls  potential  printed  output. 
NOTES,  if  turned  on,  allows  all  note  level  messages  to  be  issued.  NOTES 
are  usually  of  only  passing  or  documentary  interest  to  the  user  and  so  are 
not  always  needed. 

STATS  controls  the  collection  and  printing  of  statistical  informa- 
tion. The  total  extent  of  what  constitutes  statistical  information  is  left 
to  the  implementor,  but  should  at  least  be  a table  of  rule  invocation 
frequencies. 

TRACE  allows  the  user  to  optionally  follow  the  execution  of  the  FCF 
at  two  levels.  If  set  from  its  default  value  of  OFF  to  either  LOW  or  HIGH, 
the  FCF  user  can  trace  the  flow  of  FCF  processing.  At  LOW,  the  trace  fea- 
ture will  output  FCF  rule  entries  and  exits,  input  parsing  progress,  and 
error  messages.  When  set  to  HIGH,  all  of  the  above  is  indicated  along  with 
an  indication  of  which  statements  in  the  FCF  were  executed  and  symbol 
table  manipulation  messages. 

XREF  specifies  that  a cross  reference  listing  is  to  be  generated 
indicating  all  symbol  table  entries  and  where  they  are  referenced.  Since 
the  entire  FCF  must  be  processed  (but  not  necessarily  executed)  to  obtain 
the  listing,  setting  the  FUNCTION  switch  to  SYNTAX  in  conjunction  with 
setting  XREF  on  insures  that  a complete  cross  reference  listing  will  be 
made.  Otherwise,  there  exists  the  possibility  that  a fatal  error  will 
inhibit  precompiler  functions  before  the  cross  reference  is  complete. 
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The  OUTPUT  switch  controls  which  type  of  format  the  customized  pre- 
compiler output  will  follow.  If  set  to  FORTRAN,  the  initialized  value, 
the  output  will  be  processed  so  as  to  conform  to  FORTRAN  card  image  format. 
Continuation  cards  will  be  generated  automatically  as  needed  and  sequence 
numbers  supplied.  If  set  to  DATA,  no  special  card  image  format  is  produced, 
output  is  transferred  directly  without  checking  column  alignments 
or  adding  sequence  numbers. 


4.0  ILLUSTRATIVE  EXAMPLE 


To  provide  a clearer  concept  of  how  the  precompiler  will  operate, 
an  example  is  provided  here.  Although  not  all  features  nor  control  state- 
ments are  utilized  in  this  example,  it  contains  sufficient  detail  to  demon- 
strate most  of  the  salient  features  of  the  precompiler  design.  The  example 
itself  consists  primarily  of  FCF  control  statements,  with  only  enough  im- 
bedded FORTRAN  actually  appearing  in  the  listings  to  provide  an  adequate 
frame  of  reference.  In  actual  practice,  the  ratio  of  FORTRAN  statements 
to  FCF  control  statements  will  most  likely  be  quite  high. 

4.1  DESCRIPTION  OF  EXAMPLE 

This  example  shows  how  a typical  FCF  and  its  associated  input  file 
might  appear.  The  portion  of  the  FCF  shown  is  customizing  a section  of  a 
main  program  that  may  or  may  not  include  a call  to  a specific  subroutine. 

The  subroutine  in  question  is  called  HETEST  and  has  as  part  of  its  function 
the  calculation  of  energy  height  parameters.  The  subroutine  has  no  arguments, 
so  that  the  data  it  calculates  is  shared  with  the  main  program  through  a 
common  block  called  HECOM.  If  the  subroutine  is  called,  the  common  block 
should  be  included  as  part  of  the  main  program.  To  complicate  matters,  the 
HETEST  subroutine  can  calculate  energy  height  in  several  ways.  Only  the 
code  necessary,  based  upon  the  engineer's  input  requests,  is  to  be  generated 
for  input  to  the  compiler. 

Additionally,  under  certain  circumstances,  some  specific  data  values 
are  needed  in  the  HETEST  subroutine  to  make  modifications  to  the  energy 
height  parameters.  These  data  can  be  calculated  at  precompile  time  by  anyone 
of  a number  of  different  procedures.  Which  procedure  depends  upon  the  type 
of  results  being  produced.  The  data  are  to  appear  as  a data  statement  within 
HETEST  after  it  has  been  calculated.  The  engineer  on  this  project  has 
developed  a new  procedure  to  calculate  these  data  and  wants  to  incorporate 
his  procedure  into  the  FCF  to  show  that  the  resulting  code  provides 
an  improvement  over  conventional  methods.  His  procedure  involves  reading 
in  a table  of  values  derived  from  some  existing  source  as  input  to  an 
interpolation  routine.  Further  project  specific  data  is  read  in  as  input 
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to  the  same  interpolation  routine  to  evaluate  the  necessary  data  velues. 

The  engineer's  interpolation  routine  already  exists  as  a FORTRAN  code 
called  POLY. 

The  following  FCF  code  shows  one  of  many  possible  ways  to  accomplish 
the  above.  In  this  procedure  there  are  four  FCF  rules  being  used.  The 
MAIN  rule  which  controls  all  processing  invokes  a rule  named  HETEST  if  the 
energy  height  parameters  are  needed  by  the  main  program.  The  user  indicates 
this  by  the  appearance  of  ENERGY_HEIGHT  as  a subnode  of  REQUIRED_COMPUTA- 
TIONS.  The  HETEST  rule  is  located  after  the  main  rule  in  the  FCF.  HETEST 
in  turn  invokes  a specified  rule  if  there  is  to  be  a modification  of  the 
energy  height  values.  The  user  indicates  this  by  the  appearance  of  a first 
level  node  in  input  beginning  with  the  expression  INTERPOLATION_ROUTI^l 
The  specific  rule  name  is  read  from  input  and  in  this  example  is  named 
POLY.  Since  POLY  is  a special  rule  designed  to  accomplish  the  engineer's 
specific  objectives,  it  appears  in  the  special  rule  section  of  the  input 
file.  If  there  is  a subnode  of  INTERPOLATION_ROUTINE  labeled  TABLEJNFORMA- 
TION,  POLY  reads  the  necessary  table  from  input  by  invoking  a rule  named 
TA6LE_R£AD.  Because  of  the  general  purpose  nature  of  this  last  rule,  it 
is  assumed  to  have  been  previously  written  and  tested  and  to  be  found  in  an 
FCF  user's  library.  For  convenience,  its  listing  is  provided  at  the  end 
of  the  FCF  file. 

In  addition  to  invoking  several  rules,  this  example  shows  several 
other  useful  techniques.  The  use  of  the  CONSTANTS  table  in  the  main  rule 
illustrates  how  both  default  values  ♦^^or  constants  can  be  incorporated  into 
the  FCF  and  how  values  input  can  be  checked  to  insure  only  leyai  constants 
are  specified.  Specifically,  the  use  of  the  SYMBOL_EXISTS  statement  is 
used  to  verify  that  the  constant  name  input  matches  an  entry  in  the  table 
CONSTANTS.  In  this  instance,  only  RE  and  HAV  are  shown  since  they  are  used 
elsewhere  in  the  example. 

Notice  that  NODE_EXISTS  statements  appear  in  many  locations  through- 
out the  FCF.  These  tests  prove  invaluable  in  structuring  FORTRAN  code 
which,  based  upon  the  same  specified  input,  might  require  FORTRAN  state- 
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ments  to  appear  in  several  different  locations.  Recall  that  the  N0DE_ 
EXISTS  statement  does  not  alter  the  current  location  of  the  input  parsing 
pointer  as  do  FIND  and  INPUT,  but  simply  tests  to  see  if  the  specified 
input  appears  in  the  input  file. 


In  addition  to  standard  symbol  table  constructs,  this  example  also 
shows  the  use  of  the  special  subscript  notation  for  table  references  by 
use  of  the  DEFINE  statement.  To  read  in  groups  of  values,  such  as  in  a 
table,  this  proves  much  more  convenient.  Additionally,  when  passing  array 
data  to  an  executable  FORTRAN  code,  this  form  of  specifying  tables  is  much 
more  readable.  See  the  TABLE_READ  rule  listing  for  examples  of  its  use. 


Also,  the  use  of  the  DEFINE  statement  to  establish  a table  name 
equivalence  is  shown.  The  TABLE_READ  rule  stores  information  in  a table 
called  TABLE;  the  rule  named  POLY  uses  the  TABLE_READ  rule  but  refers  to 
data  as  if  it  were  stored  in  a table  named  P0LY_TAB.  By  use  of  the 
DEFINE... AS  statement,  these  two  names  can  be  made  to  refer  to  the  same 
table,  so  that  the  data  read  by  TABLE_READ  is  actually  stored  in  P0LY_TA3. 
After  TABLE_READ  is  finished,  the  equivalence  is  removed  by  use  of  the 
DEFINE... AS  NULL  statement.  All  table  data  input  is  still  accessable  by 
the  table  name  P0LY_TAB.  This  use  of  the  DEFINE... AS  statement  provides 
a powerful  capability  for  using  rules  in  a subroutine-like  context. 


The  computation  of  precompile  time  values  can  also  be  very  important. 
This  example  shows  two  possible  ways  of  accomplishing  this.  With  use  of 
the  PARAMETERS  and  EXECUTE  statements,  the  user  can  compute  very  com- 
plicated function  values,  or  whatever,  by  use  of  already  developed  FORTRAN 
packages.  In  rule  POLY,  a FORTRAN  routine  named  POLY  is  executed  to  compute 
the  data  values  for  inclusion  in  a data  statement.  Another  procedure, 
useful  for  simpler  tasks,  is  to  use  an  arithmetic  expression  directly 
when  entering  values  into  a symbol  table.  An  example  of  this  is  provided 
in  rule  HETEST  when  the  value  of  6R  is  entered  into  the  PASSl  table. 


Since  customized  FORTRAN  output  is  a principal  aim  of  the  precompiler, 
numerous  instances  of  both  synthesized  and  direct  output  of  FORTRAN  are 
given.  Notice  also  the  use  of  the  PASSl  and  PASS2  tables  in  the  modifica- 
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tion  of  the  FORTRAN  code.  Both  the  MAIN  rule  and  HETEST  contain  examples 
of  the  use  of  these  special  tables. 


The  following  sections  provide  listings  for  the  input  file  and  the 
various  rules  used  from  the  FCF.  Section  4.4  describes  the  possible  outputs 
generated  by  the  precompiler.  Notice,  in  particular,  the  precompiler  run 
using  the  trace  feature  set  to  high.  By  following  the  FCF  code  that  is 
highlighted  with  bold  print  and  the  annotations  at  the  far  right  of  the 
listings,  it  is  possible  to  see  how  the  FCF  is  processed. 


1 

i 

I 


4,i  THE  INPUT  SPECIFICATION 


/•  S4NPLI  INPUT  PILE  •/ 


CONSTANTS 

HAV  ■ 23000. 
fifOPNTSlCAL.NODCL 
EARTH 

spherical 

NON  ROTATINC 
SRAVITT 

VARIARLE 

RERUIRIO. computations 
■NIRGV.HIICHT 

INTCRPOLATION.ROUTINE  • POLT 
TAILE  INPORNATION 

/•'default  value  for  COLUMNS  IS  2 •/ 


ROUS 

• 5 

DATA 

• 0. 

24.3 

s. 

49.8 

11. 

74.3 

17.5 

89.1 

20. 

99.7 

INTERPOLATION .VALUES  • 1 .4 3 .2 . 1 ,4 .2 ,1 1 .0, 1 9 .5 

/•  values  used  as  input  to  interpclation  routine  •/ 


p /•  special  rule  section  •/ 

P POLTi 

P 00  FOR  SYHROL  TABLE  POLY 

• /•  special  rule  that  creates  data  statements  */ 

P /•  BASED  ON  VALUES  DETERPINEO  BY  INTERPOLATION  •/ 

• IF  NODE  EXISTSIa. table. INFORMATION) 

P THEN  DO 

P DEFINE  TABLE  AS  POLY  TAB 

P INVOKE  TABLE  READ 

P DEFINE  TABLE  AS  NULL 

P END 

P /•  TABLE  READ  IS  AN  EXAMPLE  OF  A RULE  THAT  MIGHT  RE  FOUND  •/ 

p /*  IN  an'fcf  users  library— see  bottom  of  run  */ 

P /•  READS  data  into  table  NAMED  TA9Lt2  AND  SHE  INFC  INTO  •/ 

• /•  SYMBOLS  COLUMNS  AND  ROWS  IN  CURRENTLY  DEFINED  DEFAULT  •/ 

P /♦  SYMBOL  table  •/ 

P ELSE  . 


P define  X(10>,Y(10>  /•  DEFINE  TUO  TABLES  OF  FIXED  (10)  LENGTHS  •/ 

P FiNOdNTCRPOLATION  ROU T INE . INTERPOL AT  ION  VALUES) 

P ERROR:  DO  . 

P END 
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/•  S4MPL(  IN^Ur  nit  COkriNUfD  •/ 


ik 


SET(N-Q> 

00  UHlLf  INPUTC,*  00  ■■') 

INCRCNCNTtN) 

ir  N > 10  THIN  NISSAfiI(I,*S:TOO  NANT  VALUIS  READ  IN') 

INNUTTNUNaiN)  ERROII:  NESSASf  ( I , ' S INUNBIRS  ARE  TNI  ONLY  VALID  INPUTS') 
INTIR<X(N),*> 

END 

ir  N > 0 
THEN  00 

PARANiriRS  POLr(REAL(COLUNNS,ROHS) ,INTE6ER«INTECER«REAL(N> ,REAL(N)> 
EXECUTE  POLTIPOLT  TAB <1 > , COLUNNS «ROHS,X ( 1) ,T ( 1 ) > 

/•  CONPUTE  T VALUES  TRON  CIVEN  X'S  USINC  DATA  TOUNO  IN  POLT  TAB  •/ 
SETCOATA  ST  ■ 'DATA  VALUES/')  /•  START  BUILOINC  DATA  STATENENT  •/ 
SET<r«0)' 

00  UNILE  I<N 
INCRENENTd) 

C ATEN ATE (OE/AULT«OATA_ST« value (T(I) ) FORNATI TA.I ) ) 

IF  ION  THEN  CATENATE(0EFAULT,0ATA  ST,',') 

ELSE  CATENATE ( DEFAULT, DATA. ST,'/') 

ENO 

OUTPUT! 'DINENSION  VALUES!', N ■>  I ,')',t) 

/•  INCLUDE  PROPERLY  OINENSIONEO  VARIABLE  NAPE  •/ 

OUTPUT!OATA  ST,R)  /•  OUTPUT  FORTRAN  DATA  STATEPENT  •/ 

ENO 

ELSE  00 


ENO 

/•  NOU  ELININATE  UNNECESSARY  TABLE  STORACE  •/ 
ENO  /•  ENO  OF  default  SYNBOL  TABLE  BLOCK  •/ 
CLEAR  TABLEIX) 

clear'tablecy) 

CLEAR~TABLE!P0LY.TAB) 

CLEAR_TABLS!P0LY) 

ENB  POLY 


ENO  OF  INPUT  file 


p 


sample  rcF  file 


••••/ 


P MAIN: 

P SETITRACE  - •H16M')  /•  USE  TRACE  FEATURE  TO  MONITOR  FCF  PROCESSING  •/ 

« P 00  FOR  SYMBOL  TABLE  CONSTANTS  /•  SET  UP  TABLE  FOR  LEGAL  VARIABLE  NAMES  •/ 

P SETIHAV  ■ 20000.) 

P SETCRE  ■ 209264258.) 

• • I 


P END 

P 00  FOR  EACH  SUBNOOE  OF  CONSTANTS  /•  REAO  IN  CONSTANTS  FROM  INPUT  •/ 

P INPUT(UORO)  ERR0R:NESSA6E(*IS:ILLC6AL  CONSTANT  NAPE') 

P SYMBOL  EXrSTSCCONSTANTS,*)  /*  CHECK  TO  SEE  IF  THIS  IS  A LEGAL  CONSTANT  ♦/ 

P ERROR:NCSSA6E(I.'S:CONSTANT  NAME  NOT  RECOGNIZED') 

P ENTERCCONSTANTS,*)  /*  ENTER  SYMBOL  FROM  INPUT  INTO  CONSTANTS  TABLE  •/ 

P INPUT('a')  ERR0R:NESSA6E('IH:MISSING  EOUAL  SIGN')) 

P INPUTICONSTANT)  ERR0R:MGSSA6E( 'IS:ZLLEGAL  CONSTANT  VALUE') 

P ENTERO,*) 

P END 


PROGRAM  SAMPLE 

P IF  NODE  E*ISTS(REaolRED_C0MPUTATI0NS.£NER6Y_HEICMT) 

P tmen"output(»necom,») 

P /•  HECOM  IS  A PLACE  HOLDER  FOR  A COMMON  BLOCK.  IT  WILL  •/ 

P /•  BE  REPLACED  BY  THE  PROPER  FORTRAN  ON  PASS2  SUBSTITUTION  •/ 


I 

■ 


P IF  node  EXISTSIREQUIRED  computations. ENERGY.HEIGHT)  THEN 
P /•  INCLUDE  A call  TO  THE  PROPER  FORTRAN  SUBROUTINE  •/ 

call  HETEST 


call  exit 

END 

P /*  END  OF  THE  MAIN  PROGRAM  BUT  NOT  NECESSARILY  OF  THE  "AIN  FCF  RULE  •/ 


P IF  NODE  EXISTSIREOUIRED. COMPUTATIONS. ENERGY. HEIGHT) 

P THEn'inVOKE  HETEST  /•  TRANSFER  OF  CONTROL  TO  SPECIAI  FCF  PULE  */ 


P ENOMAIN  /•  END  OF  MAIN  FCF  RULE  */ 


p 


/ •••• 


SAPPUC  flLC  CONTINUCO 


/ 


P /*  MCTEjT  ts  ANOTHER  RULE  WITHIN  TnE  CURRENT  FCF  •/ 

P HETEST: 

SU8R0UTINE  HETEST 

RhECOH  /•  PLACE  HOLDER  TOR  PASS  2 INSERTION  Of  COHPON  ELOCK  */ 


) 

I 

[ 


P 

P 

P 

P 

P 

P 

P 


/•  PERfORN  CONPUTATIONS  TO  INSERT  DATA  STATEHENT  •/ 

IF  riNOIINTERPOLATION.ROUTINE) 

THEN  DO 

INPUTC*')  ERROR:nESSACE(l,'W:EaUALS  SICN  PISSINC) 

INPUT(UORD)  /•  READ  RULE  NAPE  FROfl  INPUT  •/ 

INVOKE  • /•  transfer  CONTROL  TO  SPECIAL  RULE  — FOUND  IN  INPUT  •/ 

ENO 


P ENTER (PASS t,RE,VALUE( CONST ANTS,RE)> 

P ENTER(PASS1,CR,£RAV.CONST*NASSt*nASS2/VALUE(PA$S1,R£>**2) 

B /•  ENTER  COnPUTEo'vALUE  FOR  CR  INTO  PASS1  TABLE  */ 

P /•  6RAV  CONST, HASS1,nASS2  ARE  ASSUMED  TO  BE  VALID  SYMBOL  TABLE  ENTRIES  •/ 

p ENTER(PASS2,«NEC0n, •COHMON/HECOn/  NT(2C>,  HET(20>'>  /•  UPDATE  HECOM  •/ 


P 

P 

P 

P 


P 

P 

P 


P 

P 

P 

P 

P 


DO  90C  J>1,2C 

IF  NODE  EXISTSCCEOPHTSICAL.MOOEL. EARTH. SPHERICAL)  AND 
NODE  EXISTS (SEOPHYSICAL  NODE L .EARTH . NON-RO TA TINC > AND 
N00£"EXlSTS<SE0PHtSICALlM0DEL.6RAWITY. CONST  ANT) 

THEN  DO 

READIS.IOON)  HT<J) 

HET(J)  a hT(J) 

ENO 

ELSE  DO 

CATENATE  (PASS2,»MECO.N,',  VTT(20)')  /•  ADO  PORE  TO  COPHON  BLOCK  •/ 

REAO(S,1019>  HT(J),VTT(J) 

HET(J)  a RE/(RE*HAV)aCSL/CRaHT(J)»VTT(J)**2/(2.*6R) 

/•  RE  AND  6R  HAVE  VALUES  FROM  PASS)  TABLE  SUBSTITUTED  ON  OUTPUT  •/ 
aELETE(PASS1,RE) 

OELETE(PASS1,SR) 

/a  RE  AND  GR  ELIHINATED  FROM  PA$S1  TABLE—CANNOT  BE  SUBSTITUTED  ANY  LONGER 
END 

900  CONTINUE 


•/ 


SAMPLE  FCr  FILE  CONTINUED 


RETURN 

END 

END  NETEST 


/•  FCF  RULES  USED  BY  MANY  SOURCES  CAN  BE  SAVED  IN  AN  FCF  USERS  LIBRARY  •/ 
/•  THIS  IS  ONE  OF  MANY  RULES  THAT  MAT  BE  LOCATED  IN  A COMMON  LOCATION  •/ 


TABLE.REAO: 

/•  THIS  RULE  READS  TWO  DIMENSIONAL  TABLES.  THE  FOLLOblNO  INFORMATION 
/•  IS  READ  FROM  INPUT:  NUMBER  OF  COLUMNS  (OPTIONAL,  DEFAULT  ■ Z) 

/•  NUMBER  OF  ROWS  (OPTIONAL,  DEFAULT  ■ TO),  TABLE  DATA  ENTRIES  BY  ROW 
/•  DATA  SHOULD  BE  0R6ANIZED  IN  INPUT  IN  THE  FOLLOUINC  FORMAT: 

/•  XXXXXRX  (NODE  IDENTIFYING  WHICH  TABLE— POSl TICNED  BY  USER) 

/•  TABLE. INFORMATION  (IDENTIFIES  BEGINNING  OF  TABLE  INFO) 

/•  columns  • (NUMBER  — IF  NOT  PRESENT,  SET  TO  Z) 

/•  ROWS  ■ (NUMBER  — IF  NOT  PRESENT,  SET  TO  TO 

/•  DATA  ■ table  values  BY  ROW  SEPARATED  BY  BLANKS  OR  COMMAS 

/•  TABLE  DATA  IS  STORED  IN  A TABLE  NAMED  TABLE  . NO.  OF  COLUMNS  Af.'S 
/•  ROUS  IS  SAVED  IN  CURRENT  DEFAULT  SYMBOL  TABLE  AS  COLUMNS  AND  ROWS 
FINOO.TABLE.INFORNATION) 

SAVE  pointer 
IF  FINDCa. COLUMNS) 

THEN  DO 

IMPUT( •••) 

:nput(number) 

SETCCOLUMNS  ■ •) 

END 

ELSE  SETCCOLUMNS  ■ 2)  /•  DEFAULT  NO.  OF  COLUMNS  */ 

RESTORE.POINTER 
SAVE  POINTER 
IF  FtNO(R.ROWS> 

THEN  DO 

INPUT! •••) 

INPUT(NUMBER> 

SETCROWS  ■ •) 

END 

ELSE  SETCROWS  « 1C)  /•  DEFAULT  NO.  OF  ROWS  •/ 

DEFINE  TABLI<COLUMNS,ROUS) 

RESTORE.  POINTER 

FINOCa.OATA)  ERROR:  MESSAGE (' 1 S : TABLE  DATA  MISSING') 

INPUT! •••) 

SETIN-I) 

DO  while  N <■  ROWS 
$ET(M  ■ 1) 

CO  WHILE  M <■  COLUMNS 


SA«^t€  fCf  riLE  CONTiNUeO 


• ••«/ 


p 

p 

p 

p 

p 

p 

p 

p 

p 


INPUTCCONSTANT) 

ENTERCTAaLEC.t^N),*} 

INCIIENCNr(.<l) 

IE  INROK*,*)  THEN  00  END 

/*  IE  THERE  IS  * COEINA,  READ  IT 

ENO 

INCRENENTIN) 

ENO 

ENO  TAILE  REAO 
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IN  BUT  00  NOTHINC  •/ 


4.4  THE  PRECOMPILER  OUTPUT 


Understanding  the  operation  of  the  precompiler  can  probably  be  best 
accomplished  by  examining  its  output.  Although  only  a portion  of  what  the 
actual  output  might  look  like,  the  following  subsections  provide  listings 
of  a simulated  precompiler  run  of  the  example  described  above.  The  first 
subsection  lists  all  FORTRAN  directly  output  or  synthesized  by  the  pre- 
compiler run.  Although  seemingly  very  little,  large  blocks  of  FORTRAN 
code  could  have  been  output  in  the  missing  sections. 

The  following  subsection  lists  output  produced  by  both  error  and 
trace  conditions.  The  input  file  error  conditions  were  written  by  the 
MESSAGE  command  as  directed  by  the  FCF.  The  FCF  error  messages  were  written 
by  the  precompiler  because  of  the  indicated  syntactic  errors.  Both  the 
severe  errors  in  the  input  and  the  FCF  files  would  inhibit  the  successful 
completion  of  a precompiler  run.  The  last  output  in  this  section  provides 
the  details  of  a completed  precompiler  run  with  the  TRACE  switch  set  to 
high.  This  output  provides  an  excellent  means  of  tracing  the  actual  opera- 
tion of  the  precompiler.  The  annotations  to  the  right  of  the  actual  FCF 
control  statements  are  output  during  the  trace  mode  and  indicate  the  opera- 
tions actually  performed  by  the  precompiler.  Note  that  SYMBOL  indicates 
a symbol  table  operation,  INPUT  an  input  file  operation,  and  OUTPUT  an 
actual  FORTRAN  statement  written  out.  Note  that  on  output,  an  * indicates 
the  line  was  written  out  as  it  appears.  Other  annotations  that  appear 
are  self-explanatory.  The  FCF  code  actually  executed  appears  in  bold  type. 

In  the  last  subsection,  a sample  statistical  and  cross  reference 
suimary  are  produced.  Note  that  both  are  incomplete  and  could  possibly 
contain  additional  information  when  actually  inplemented. 


4.4.1  FORTRAN  Output 

S*1f»LE  FORTRAN  OUTPUT  FOR  IULUSTRATWS  EXAMPLE 
PROGRAN  sanple 

CORRON/HECON/  ^T(20>,  HET(23),  \/TT(20) 


CALL  HETCST 


CALL  EXIT 
END 


SUBROUTINE  METEST 

CORRON/HECOR/  HT(2Q),  HET(20),  VTT(20) 
OIRENSION  t/ALUES(S) 

DATA  WALUES/33.9,41 . 6,71 . 5,77. 3, 97. 1 / 


• 

DO  930  J«1,23 

REA0(5,1319)  HT<J),  VTT(J) 

NET(J)  - 2.09254258E«*37/(2.09264258E^07>23000)*GSL/32.2456*HT(J)  ♦ 
1VTT(J)**2/{2.*32.2456) 

903  CONTINUE 


RETURN 

END 


4-12 


4.4.2  Trace  and  Error  Messages 


AN  EXAMPLE  OF  INPUT  FILE  ERROR  MESSAGES 


i 


INi»ur  FILE: 


CONSTANTS 

HAU  « 23000 

* 

***  s ***  CONSTANT  NAME  NOT  RECOGNIZED 
GEOPHYSICAL  MODEL 
EARTH 

SPHERICAL 
NON  ROTATING 
GRAVITY 

VARIABLE 

REQUIRED  COMPUTATIONS 
ENERGY.WEIGHT 

* 

***  y ***  UNUSED  INPUT 

INTERPOLATION  ROUTINE  = POLY 


TABLE.INFORMATION 

DEFAULT 
ROWS  = 5 

VALUE  FOR 

COLUMNS  IS  2 */ 

DATA  s 0. 

26.3 

5. 

69. S 

11  . 

76.3 

17.5 

89.1 

20. 

99.7 

INTERPOLATION 

.values  = 

1 .63^2.1,6.2,1 1.6,19.3 

***  INPUT  ERROR  SUMMARY 
***  1 SEVERE  ERRORS  *** 

***  1 WARNINGS  *** 

n NOTES  *** 
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*N  example  or  rcf  error  'aessaces 

P <AIH: 

P SETCTRACE  « 'HIGH’)  /•  USE  TRACE  TEATURE  TO  "ONITOR  fCf  PPOCESSIAG  •/ 

P DO  roR  STPSOL  TA8LE  CONSTANTS  /•  SET  UP  TAALE  TOR  LEGAL  VARIABLE  NAMES  */ 

P SETEHAV  • 20000 

P SETERE  • 209264258) 


P END 

P DO  fOR  EACH  SUBNOOE  Of  CONSTANTS  /»  READ  If-  CONSTANTS  fPOM  INPUT  •/ 

P INPUTEWOHO)  ERR0R:.’’.ESSAGEE1,*S:ILLC6AL  CONSTANT  NAME’) 

P Sr«aOL  existselegal,*)  /•  check  to  see  that  this  is  a legal  constant  •/ 

P ERR0R:MESSAGEE1,‘S;C0NSTANT  nape  not  RECOGNIZED’) 

? EN’^ERECONSTANTS,*)  /•  ENTER  SYMBOL  fROM  INPUT  INTO  CCNSTANTS  TABLE  •/ 

P INPUT!’*’)  ERRORtMESSAGEEI^’Wt.'lSSING  EQUAL  SIGN’)) 

P INPUTECONSTANT)  ERR0R:MESSAGEEI,’$:ILLEGAL  CONSTANT  VALUE’) 

P ENTEREa,*) 

P END 

P ENTEREPASS2..HEC0M)  /•  SET  UP  PLACE  HOLDER  TOP  CO*MON  STATEMENTS  •/ 


missing  comma 


ASSUMED  PRESENT 


•••  $ •••  missing  or  ILLEGAL  SYMBOL  NAME 


program  SA.MPLe 

p If  NODE  EXISTS  EREQUIREO  CO.''PU  TA  T IONS  . E f.E  RG  Y_H  E IGH  T ) 

P THN  OUTPUTERHECOM,*)" 

* 

S •••  EXPECTED  ’THEN*  CLAUSE  IN  AN  ’If’  STATEMENT  WAS  NOT  FOUND 
P /•  HECOM  IS  A PLACE  HOLDER  FOR  A COMMON  BLOCK.  IT  HILL  */ 

P /•  3E  REPLACED  BY  THE  PROPER  FORTRAN  ON  PASS2  SUBSTITUTION  •/ 


P IF  NOOE.£XISTSEREGUIREO_COflPurATIOMS.£NERGY_HEIGHT)  THEN 

P /•  INCLUDE  A CALL  To”thE  PROPER  FORTRAN  SUBROUTINE  •/ 

call  hETEST 


call  exit 

END 

P /•  END  Of  THE  MAIN  PROGRAM  BUT  NOT  NECESSARILY  Cf  TNE  '•AIN  FCF  RULE  •/ 


P IF  NODE  EX  1 STS  (REQU  IRE  O.CC.YPUTA  TICNS  .E  NE  RGY_hE  IGH  r ) 

? TH£n“inV0KE  HETEST  '/•  TRANSFER  Of  CONTROL  TO  'OECIH  FCF  RULE 


P END  '•AI'I  /•  END  Of  MAIN  FCF  RULE  •/ 


•••  FCF  ERROR  SU-IMARY 
•**  2 SEVERE  ERRORS  ••• 

•••  1 «ARfi'NGS 

•••  1 'lOTES 
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II  ^i(iCO«Plili  ; Jill  I 


HACt  L04  commuio  **  nio*':  fAicoAf^itir:  juit  is«19;8  tacc  4 

MUtklk^il  • >6414  tf4LUf$/*>  /•  STAAT  aUlLOlNC  OAU  SIATIMEMI  •/  4%lPbOli  <»OtV,DATA 


' >»*  ** 
IMI 


tsn 

LSf  DO 

CAICNAIf  (PASS?,iHf  VTT(20)*>  /•  ADD  ftOR£  10  CCKffOh  BLOCK  •/  ♦SVIIHOLS  (PASS2#HCC0n)  sCOMRON/HiCOB/ 

M1(?0>«  NCf<^U>«  Vlf(?0) 


4.4.3  Summary  Statistics 

SA'I^LE  Of  SJ'I'IASy  STATISTICS 

?UL£  INVOCATION  F9E3UENCIES 

^ULE  INVOICED  FRON  FSEauENCY 

3XSS  saaaaaaaaasx  aaaaaaaaa 

NETEST  NAIN  1 

»0LY  HETEST  1 

TA3LE_READ  poly  7 


SA'I^lE  of  SY'iaOL  CROSS  REFERENCE  'lAP 


RJLE:  '*AI'| 
TABLE 

3ZS3  3 

CD'JSTAMTS 

legal 

PASS2 

m 

RJLE:  TA9LE 
TABLE 

aa  as  s 

•OEFA'JLT* 

TA3LE2 


SY'iaOL 

3SS3Z3 


REFERE'ICES 

S3 3 3 3X3 S 33 

9 2*  , . . . 


m 

HAV  2,7,... 

RE  3,... 


HECO'< 


11 


, ..  . 


READ 

SY'iaOL  REFERENCES 

33333  3 =S  = 33==;SSS 


COLUMNS 

>1 

N 

ROWS 

•ARRAY  TABLE* 


7*,9*,... 

20*,.  .. 

1 8*,.  .. 

14*, 1 5*,... 
16,24*,... 
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5.0  SPECIFICATION  MECHANISMS  USED 


To  functionally  specify  the  FLTOPS  design,  several  distinct,  yet 
complementary,  mechanisms  have  been  used.  The  principal  specification 
mechanism  used  has  been  an  augmented  grammar  technique.  This  technique 
combines  classical  syntactic  specifications  with  embedded  semantic  in- 
formation to  rigorously  define  design  requirements. 

The  semantic  content  of  the  augmented  grammar  is  embodied  in  a set 
known  as  the  functional  primitives.  These  functions  are  primitive  with 
respect  to  the  precompiler  since  they  define  its  primitive,  or  basic,  operations. 
These  primitives  are  specified  within  the  FLTOPS  design  by  a mechanism  known 
as  a Program  Design  Language  or  POL.  Using  programming-language-like 
constructs  combined  with  English  language  statements,  a complete,  yet  sim- 
ple and  clearly  understandable,  specification  of  each  primitive  can  be 
made. 

In  addition  to  the  use  of  POL  descriptions,  the  lexical  analyzers 
required  by  the  FLTOPS  design  use  as  part  of  their  specification  the  use  of 
state -transition  diagrams.  These  tree -structured  diagrams  describe  completely 
the  token  identification  process  of  the  individual  lexical  analyzers. 

Lastly,  the  FLTOPS  design  specification  requires  the  use  of  support- 
ing text  and  definitions.  This  additional  information  acts  as  supplemental 
data  to  the  rigorous  specifications  already  afforded  by  the  augmented  gram- 
mar technique  adopted  here. 


[ Each  of  the  above  mechanisms  with  relevant  examples  is  discussed 

j I in  more  detail  in  the  remaining  portions  of  this  section. 


5.1  AUGMENTED  GRAMMAR 


In  the  augmented  gratmiar  specification  technique,  the  source  language 
is  defined  by  an  ordinary  grammar  which  contains  additional  information 
pertaining  to  its  meaning.  This  additional  semantic  information  is  used 
to  specify  what  elements  of  the  object  language  are  to  be  generated  to  cor- 
respond to  particular  source  language  elements.  The  augmented  grammar  thus 
defines  the  mapping  from  source  to  object  language.  With  the  exception  of 
a small  amount  of  supporting  text,  the  augmented  grammar  gives  a complete 
description  of  the  precompiler. 

Since  the  augmented  grammar  provides  both  the  syntactic  and  seman- 
tic content  of  the  language, both  elements  are  discussed  in  detail  in  the 
following  sections. 

5.1.1  Syntactic  Specificatior  Technique 

The  method  used  to  specify  language  syntax  is  that  typically  used 
in  modern  linguistics  to  describe  context-free  languages  by  means  of  a phrase 
structure  gramnar.  Specifically,  a notation  based  on  the  Backus-Naur  form 
(Naur,  1960)  is  used. 

Let  us  consider,  first,  a simple  example  containing  only  syntactic 
information.  Figure  3 shows  the  syntactic  definition  of  this  sample  lan- 
guage. 


G,.AL_RLL£  :»  ScNTkNCc  ; 

SENTENCE  i=  NOLiN_HHtLA  :>£  VbKa_PHAASE  ; 

NajN_PnRAE£  :»  ARTICLE  NCuN  7 
VEKa.PriKAEE  :»  V'EAb  NLUN_PHiNMSc  ; 

AkTICLc  :=  'THE”  | "A”  ; 

NOJN  ;=  "SCY"  I ••GIRL"  I "LC,,'*  | "CAT'*  ; 

Vfcftd  la  "HIT"  I •SCRATCHta*  I ••PCLLJwtL"  I ; 

. ENO 


Figure  3.  A Simple,  Purely  Syntactic  Grammar 


This  particular  language  is  sufficiently  simple  that  its  defini- 
tion can  also  be  expressed  in  English.  By  comparing  the  formal  definition 
in  Figure  3 with  the  natural -language  description  following,  the  reader 
can  easily  acquire  a feeling  for  the  metalanguage  used  in  such  formal 
definitions.  The  definition  says: 

1)  The  goal  rule  of  this  grammar  is  SENTENCE. 

2)  A sentence  consists  of  a noun  phrase  followed  by  a verb 
phrase  followed  by  a period 

3)  A noun  phrase  consists  of  an  article  followed  by  a noun. 

4)  A verb  phrase  consists  of  a verb  followed  by  a noun  phrase. 

5)  An  article  consists  of  the  word  "THE"  or  the  word  "A", 

Note  that  the  vertical  line  (|)  means  or. 

6)  A noun  consists  of  the  word  "BOY",  or  the  word  "GIRL",  or 
the  word  "DOG",  or  the  word  "CAT". 

7)  A verb  consists  of  the  word  "HIT",  or  the  word  "SCRATCHED", 
or  the  word  "FOLLOWED"  or  the  word  "LIKED". 

Such  a grammar  can  be  viewed  in  two  ways  other  than  as  a simple 
definition.  First,  it  can  be  viewed  as  a generative  grammar.  This 
particular  grammar  is  capable  of  generating  256  sentences,  such  as, 

"THE  BOY  HIT  THE  CAT",  "A  DOG  FOLLOWED  THE  GIRL",  etc.  The  generation 
of  such  sentences  is  accomplished  simply  by  starting  with  the  goal  (in 
this  case  SENTENCE)  and  substituting  its  definition  (NOUN_PHRASE  VERB_ 
PHRASE).  Definitions  are  successively  substituted  for  each  variable  that 
occurs  until  no  variables  remain.  The  resulting  string  is  an  instance 
of  the  goal  (in  this  case,  a sentence).  This  process  can  be  viewed 
as  generating  a tree  such  as  that  shown  in  Figure  4,  which  describes 
the  entire  derivation  of  a sentence,  or  the  phrase  structure  of  the 
sentence. 
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SENTENCE 


Figure  4.  A Phrase-Structure  Tree 


The  other  way  of  viewing  such  a graninar,  and  the  relevant  one 
here.  Is  as  the  deflnltlnn  of  a parsing  process.  Parsing  is  the  inverse 
of  the  generative  process.  Parsing  starts  with,  in  this  case,  a sentence 
like  THE  GIRL  LIKED  THE  DOG."  and  derives  the  underlying  structure. 
Figure  4 can,  therefore,  be  regarded  as  a parse  tree,  in  which  case  the 
string  at  the  bottom  Is  the  Initial  Information  and,  with  the  help  of 
the  grammar,  the  structure  Is  derived. 

Based  on  the  grammar  of  Figure  3,  the  parsing  of  the  sentence 
THE  GIRL  LIKED  THE  DOG."  would  proceed  as  follows.  First,  the  “goal" 
rule  of  the  granmar  is  SENTENCE.  Assume,  therefore,  that  we  are  looking 
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Figure  5.  Steps  in  the  Parsing  Process 


Figure  5 (Continued)  Steps  in  the  Parsing  Process 
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for  an  instance  of  the  entity  defined  by  the  rule  SENTENCE.  At  this 
point,  then,  the  parsing  process  has  proceeded  to  the  state  illustrated 
in  Figure  S(a),  where  the  input  string  is  illustrated  at  the  bottom  of 
the  figure,  and  the  "top-down"  parsing  process  starts,  naturally  enough, 
at  the  top.  SENTENCE,  because  it  is  not  in  quotation  marks,  is  a "non- 
terminal" symbol.  A nonterminal  symbol  must  be  defined  in  the  grammar, 
and  its  definition  can  be  substituted  for  the  symbol  itself.  Making 
this  substitution,  we  have  Figure  5(b).  Notice  that  we  have  added 
NOUN_PHRASE,  VERB_PHRASE,  and  "."  to  the  parse  tree,  because  these  three 
symbols  were  contained  in  the  definition  of  SENTENCE  given  in  Figure  3. 

Continuing  in  the  same  manner,  we  substitute  the  definition  of 
N0UN_PHRA5c  (ARTICLE  NOUN)  for  the  symbol  NOUf{_PHRASE , yielding  Figure 
5(c).  Notice  that,  in  each  step,  we  are  considering  the  leftmost  "un- 
satisfied" symbol.  Whenever  that  symbol  is  a nonterminal  symbol,  as  it 
has  been  in  all  cases  thus  far  considered,  we  substitute  its  definition. 
At  this  point,  the  leftmost  unsatisfied  symbol  is  ARTICLE.  ARTICLE,  how- 
ever, is  defined  in  terms  of  terminal  (string  literal)  symbols.  It  has, 
in  fact,  two  alternative  definitions,  "THE",  and  "A".  Considering  the 
first  definition,  we  observe  that  "THE"  is  also  the  leftmost  unused 
symbol  of  the  input  stream.  It,  therefore,  satisfies  the  definition  of 
ARTICLE,  as  Indicated  by  Figure  5(d). 

In  Figure  ^(d),  the  leftmost  unsatisfied  symbol  is  now  NOUN. 

Since  one  of  the  definitions  of  NOUN  is  "GIRL",  and  this  is  the  leftmost 
unused  symbol  in  the  input  stream,  these  two  symbols  are  connected  as 
shown  in  Figure  5(e).  At  this  point,  the  rules  ARTICLE,  NOUN,  and  there- 
fore, NOUN_PHRASE,  have  all  been  satisfied.  Our  attention,  therefore, 
turns  to  VERB_PHRASE,  which  is  further  defined  and  eventually  satisfied 
in  Figures  5(f),  5 (g),  5 (h),  5 (i),  and  5(j).  Finally,  the  only  remaining 
unsatisfied  symbol  is  (top  of  Figure  5(j))-  Since  this  is  a terminal 
symbol,  we  have  only  to  verify  that  it  is,  in  fact,  the  next  unused 
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symbol  in  the  input  stream.  Because  that  is  the  case  in  this  instance 
(bottom  of  Figure  5(j)).  we  make  the  final  connection  of  the  parse  tree, 
yielding  Figure  5 (k) . 

The  parsing  process  just  outlined  has  not  only  verified  that  the 
sentence  "THE  GIRL  LIKED  THE  DOG."  is  legal  in  the  language  of  Figure  3, 
but  has  also  derived  the  structure  of  that  sentence  (Figure  5(k)), 

Parsing  Is  the  first  step  of  the  translation  process.  Once  the  input 
string  has  been  recognized  and  its  structure  ascertained,  the  question 
of  its  meaning  (the  semantic  intent)  can  be  addressed.  This 
is  not  to  suggest  that  parsing  must  be  completed  before  the  semantic  intent 
can  be  interpreted,  but  parsing  is  logically  first. 

The  augmented  grammar  translation  method  involves  placement  of 
information  about  meaning  (e.g.,  object  code)  directly  in  the  grammar. 
Viewed  as  a translation  process,  the  result  is  that  the  meaning,  or  seman- 
tic intent,  is  interpreted  as  parsing  occurs.  How  this  is  accomplished 
will  be  seen  in  detail  in  succeeding  sections. 

A point  to  be  noted  is  that  the  structure  and  meaning  of  a lan- 
guage defined  in  this  way  is  dependent  for  its  definition  on  both  the 
augmented  grammar  and  the  parsing  properties  that  the  parser  is  assumed 
to  have.  The  meaning  of  the  individual  symbols  of  the  augmented  grammar 
is  not  necessarily  sufficient  to  fully  define  the  language.  Under 
certain  circumstances,  it  is  also  necessary  to  know  the  parsing  methoo 
employed.  Consider,  for  example,  the  following  partial  grammar  for  a pro- 
gramming language. 

SlATc.MtMl  : = 

C J IT  1C  \iiL 1 >-T wN  LNT 
I Li  t Cl.  i',u  I T i wN  AL  _ 1 1 T £i 1 J 
CI.'IHT;C.NmL_LTaT..;Mc.'i] 

•Uh”  UJiicI  1 1 "Ttc.N"  STATC.^tuT 

( "eLCL"  LTAFc-ahT  I .c.FiT  ) ; 
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To  avoid  the  necessity  for  complex  definitions  of  CONDITION  and 
UNCONDITIONAL_STATEMENT,  the  following  additional  dumny  rules  will  be 
assumed. 


CCNClTiCN  :=  ••CCNuITICr4"  ; 
UfCCi''.01TIC'NAL_:^TAT£XcNT  :*  '•  jTATsMilM"  ; 


It  can  be  seen  that  this  grannar  provides  for  nested  conditional 
statements  such  as 

IF  CONDITION  THEN  IF  CONDITION  THEN  STATEMENT  ELSE  STATEMENT. 

The  statement  Is  ambiguous,  however,  because  the  gramnar  Is  ambiguous. 
Does  the  "ELSE” -clause  go  with  the  first  or  second  "IF"?  Considered 
from  a purely  grammatical  point  of  view,  it  may  not  matter.  However, 

If  the  statement  Is  to  have  meaning,  the  ambiguity  must  be  resolved 
since  the  two  syntactic  structures  may  not  mean  the  same  thing. 

There  are  two  approaches  available  for  the  resolution  of  such 
ambiguities.  The  first,  and  undoubtedly  the  most  aesthetically  pleasing, 
is  to  rewrite  the  grammar  In  unambiguous  form.  The  grammar  for  condi- 
tional statements  can.  In  fact,  be  rewritten  so  that  any  "ELSE"-clause 
will  be  associated  with  the  innermost  "IF"  that  doesn't  yet  have  an 
"ELSE"-clause.  Unfortunately,  the  resulting  grammar  is  considerably  more 
cumbersome  than  that  just  presented.  It  is  unambiguous,  however,  and 
that  is  an  absolute  requirement. 

The  second  approach  Is  the  one  adopted  here,  both  to  keep  the 
grammar  simple  and  to  allow  some  more  powerful  specification  "tricks". 
This  approach  is  to  assume  a particular  parsing  method.  Specifically, 
top-down  deterministic  parsing  has  been  assumed.  This  assumption  allows 
otherwise  ambiguous  grammars  (such  as  that  just  presented  for  conditional 
statements)  to  be  unambiguous. 


5-9 


The  basic  properties  of  top-down  deterministic  parsing  (1) 
once  the  first  syntactic  element  in  an  expression  has  been  recognized 
in  the  input  string,  the  parser  is  conmitted  to  that  expression  and  will 
not  consider  any  alternative;  (2)  alternatives  are  considered  in  order; 
(3)  if  the  first  syntactic  element  of  an  alternative  is  not  found,  the 
next  alternative  is  considered;  (4)  reiterating  point  (1),  no  backup 
ever  occurs  once  the  first  syntactic  element  of  an  expression  has  been 
recognized. 

Let  us  consider  how  top-down  deterministic  parsing  affects  the 
parsing  of  the  statement 

IF  CONDITION  THEN  IF  CONDITION  THEN  STATEMENT  ELSE  STATEMENT 
using  the  previous  grammar  for  conditional  statements.  The  goal  is  a 
STATEMENT.  Therefore,  the  input  string  is  examined  for  concordance  with 
the  definition  of  STATEMENT.  The  first  alternative,  C0NDITI0NAL_ 
STATEMENT,  is  considered  and  its  first  syntactic  element,  "IF",  is  re- 
cognized in  the  input  string.  "CONDITION"  is  readily  identified  as  an 
instance  of  the  required  metavariable,  CONDITION,  and  "THEN"  is  recog- 
nized. The  next  required  element  in  the  CONDITIONAL_STATEMENT  defini- 
tion is  a STATEMENT.  This  makes  STATEMENT  the  goal  again,  but  the  re- 
mainder of  the  input  string  is  now 

IF  CONDITION  THEN  STATEMENT  ELSE  STATEMENT. 

This  is  readily  recognized  as  another  conditional  statement  and  the  first 
three  symbols  are  processed  hy  the  same  mechanism  as  before.  This 
returns  us  again  to  STATEMENT  as  a goal,  but  with  only 

STATEMENT  ELSE  STATEMENT 

remaining  in  the  input  string.  Since  the  next  symbol  in  the  input  string 
is  not  "IF",  the  CONDITIONALJTATEMENT  alternative  is  rejected.  "STATE- 
MENT" is  recognized  as  an  UNCQNOITIONALJSTATEMENT  and  removed  from  the 
input  string. 

Now  consider  the  current  status  of  the  parser.  It  has  just 
recognized  the  STATEMENT  element  required  by  the  definition  of  the  inside 
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CONDITIONAL_STATEMENT.  It  is  still  in  the  process  of  identifying  the 

STATEMENT  element  of  the  outside  CONDITIONALJSTATEMENT.  What  does  it  .| 

look  for  next?  The  next  element  it  seeks  is  the  symbol  "ELSE"  as  a 

part  of  the  inside  CONDITIONALJSTATEMENT.  Since  the  input  string  now 

1 ooks  1 i ke  'h 

ELSE  STATEMENT 

the  requirement  is  satisfied,  and  the  "ELSE"-clause  is  always  associated 

with  the  Innermost  CONDITIONAL_STATEMENT.  Hence,  an  ambiguous  graiunar  { 

has  been  rendered  unambiguous  in  application. 

5.1.2  Syntactic  and  Semantic  Specification  Technique 

A purely  syntactic  grammar,  such  as  that  described  in  the  preceding 
section,  specifies  the  statements  which  are  legal  in  a language  and  defines 
a parsing  process.  It  does  not,  however,  specify  the  meaning  of  the  language 
or  describe  the  functions  of  the  language.  By  adding  information  to  the 
grammar,  however,  we  can  define  what  functions  are  executed  for  any  given 
input.  Implicitly,  such  a definition  specifies  the  "meaning"  of  the  source 
language  in  terms  of  the  basic  operations  or  primitives  that  it  performs. 

A gratnnar  which  contains  this  additional  semantic  information  will  be  referred 
to  as  an  "augmented"  graomar. 

A very  simple  augmented  grammar  is  shown  in  Figure  f . This  is  a 
modified  version  of  the  purely  syntactic  grammar  of  Figure  3.  Four  output 
statements  (.OUT)  have  been  added.  Recall  that  without  these  additional 
output  elements,  the  granmar  described  a simple  pseudo-machine  which  parsed 
simple  English  sentences,  but  which  did  not  do  anything  with  them.  The  out- 
put specifications  cause  the  pseudo-machine  to  write  out  those  sentences. 

Thus,  the  grammar  of  Figure  6 describes  a "translator"  which  reads  sentences 
and  outputs  those  same  sentences. 
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G(jAL_RUL£  :=  ScNTENCS  ; 

Sa^TENCc  ;=  .NQUN_PmRAS£  VcRa_PhAAb5  .CUT(»)  ; 

NOJN.PhRASe  :=  ARTICLE  .CLTC  •*,»)  NCbN  .3tT(“  •',»)  ; 
VBB_PhRAS£  :=  VERB  .CUT("  ••  ,* ) NCUN.  PHRASE  ; 

ARTICLE  :=  "THE**  1 "A"  ; 

NCUN  :=  "SCY"  1 ''OIRL"  1 "LLC.”  I "CAT"  ; 

VERB  5*  "hlT"  I "SCRATCHED**  | "FCLLCwEC**  1 "LIKED"  ; 

.^0 


Figure  6. 


The  .OUT  statement  causes  the  pseudo-machine  to  output  one  or  more 
character  strings  as  specified  in  an  argument  list.  For  example,  the 
statement  .OUT(”  ")  causes  a single  blank  character  to  be  written  out. 

Any  string  literal  can  be  output  similarly.  There  are  also  several  special 
symbols  which  specify  output  arguments.  The  asterisk,  as  in  .OUT(*),  is 
one  of  these.  It  refers  to  the  last  terminal  symbol  which  has  been  recog- 
nized during  the  parsing  process.  For  example,  the  SENTENCE  rule  contains 
the  element  .OUT(*).  These  elements  specify  that  the  parser  is  to 
look  for  a period  and,  having  found  it,  is  to  output  the  last  token 

found  (which  is,  of  course,  the  period).  In  this  case,  the  rule  might 
have  said  .OUT("."),  with  equivalent  result.  Two  or  more  output  argu- 
ments can  be  combined  into  a list  by  placing  coirmas  between  them,  as  in 
.OUT("  ",*). 

Figure  7 is  a parse  tree  for  the  grammar  of  Figure  §.,  as  appiieo 
to  the  sentence  "THE  GIRL  LIKED  THE  DOG."  Except  for  the  added  .OUT 
statements,  the  parse  tree  is  identical  to  that  shown  in  Figure  4 and  3. 

The  sequence  of  events  which  occur  during  this  parsing  process  can  be 
determined  by  reading  the  tree  from  left  to  right.  After  the  article 
"THE"  has  been  recognized,  the  statement  .OUT("  ",*)  causes  the  output 
of  a blank  and  the  word  "THE".  In  each  case,  the  dashed  arrow  points  to 
the  last  recognized  token.  Since  the  asterisk  refers  to  the  last  recognized 
token,  the  arrows  indicate  the  character  string  which  will  be  output  by 


the  .OUT(...*)  specifications.  The  parse  tree  indicates  that  eleven  out- 
puts occur  when  this  particular  sentence  is  executed.  These  outputs  are: 


Figure  7.  Parse  Tree  for  Augmented  Grammar  of  Figure  6 

H (blank) 

THE 

GIRL 

LIKED 

Ifi 

THE 

jj  

DOG 
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The  blank  at  the  beginning  of  the  sentence  could  have  been  avoided, 
but  the  granmar  would  have  been  somewhat  more  complicated. 

It  should  be  kept  in  mind  that  the  grammar  describes  the  function 
of  a pseudo-machine.  As  such,  .OUT  in  the  above  example  describes  an  out- 
put of  the  pseudo-machine.  The  mechanism  by  which  this  output  is  produced 
at  execution  time  is  contained  in  the  description  of  the  .OUT  primitive 
operation.  This  description  might  take  the  form  of  a detailed  object 
code  program,  flowchart  descriptors  of  information  flow  or  the  use  of  a 
program  design  language.  Because  of  its  ease  and  high  degree  of  readability, 
the  use  of  a POL  to  describe  such  primitive  operations  as  used  by  a granmar 
is  reconmended.  References  to  any  number  of  primitives  can  appear  embedded 
within  the  syntactic  description  of  the  language  as  they  are  required  to 
describe  the  translation  process. 


5-14 


5.2  PROGRAM  DESIGN  LANGUAGE  (PDL) 


The  use  of  a Program  Design  Language, or  PDL,  in  detailing  program 
design  specifications  is  relatively  new.  Classical  methods,  such  as  flow- 
chart descriptions,  have  proved  to  be  time-consuming  to  produce,  as  well  as 
very  difficult  to  follow  because  of  the  technical  nature  of  the  presenta- 
tion. On  the  other  hand,  a PDL  is  a non-technical , English-like  form  of 
notation  which  uses  a few  programming  language  structures  to  convey  program 
logic  precisely  without  sacrificing  readability.  The  PDL  syntax  and  basic 
structure  used  here  is  based  on  that  of  the  programming  language  PL/1. 

A series  of  PDL  statements  which  perform  a task  is  called  a proce- 
dure, or  in  the  context  of  the  augmented  grammar  specification  technique, 
a primitive.  PDL  statements  are  separated  by  semicolons  (;),  with  each 
primitive  being  terminated  by  an  END  statement  appropriately  labeled  with 
the  name  of  that  primitive.  Each  new  statement  begins  on  a new  line,  with 
those  statements  requiring  multiple  lines  having  each  continuation  line 
indented  some  number  of  spaces.  PDL  statements  consist  of  a few  control 
structures  that  influence  the  order  in  which  PDL  statements  are  executed. 
Execute  in  this  context  has  a special  meaning  since  the  reader  of  the  PDL 
is  doing  the  "executing"  and  not  a computer.  In  the  examples  that  follow, 
all  control  structures  will  be  capitalized  so  that  they  stand  out.  Except 
for  control  structures,  all  PDL  statements  are  written  in  non-technical 
English. 

The  IF  control  structure  is  used  to  make  a decision  with  two  possible 
outcomes.  It  looks  like  this: 

IF  condition 
THEN  statement 
ELSE  statement 


Condition  is  a proposition  which  may  be  true  or  false.  If  the  con- 
dition proves  to  be  true,  the  THEN  statement  would  be  executed.  If  false, 
the  ELSE  statement  would  be  executed.  The  appearance  of  the  ELSE  is  op- 
tional, appearing  only  if  an  either/or  condition  exists.  Otherwise  a simple 
IF... THEN...  is  sufficient. 

As  an  example  of  an  IF  structure: 

IF  you  have  finished  your  test; 

THEN  hand  it  in; 

ELSE  continue  working  on  it; 

IF  it  is  after  10  p.m.  THEN  go  to  bed; 

The  IF  structures  can  be  nested.  This  means  that  the  THEN  or  ELSE 
(or  both)  statements  may  be  another  IF  structure.  Therefore,  decisions 
with  more  than  two  possible  outcomes  can  be  made.  As  an  example,  consider: 

IF  you  are  lost 

THEN  IF  you  see  a policeman 
THEN  ask  him  for  help; 

ELSE  ask  any  grown-up  for  help; 

ELSE  IF  you  have  carfare 
THEN  take  a bus  home; 

ELSE  walk  home. 

Notice  that  the  nested  statements  are  indented.  This  is  a POL  con- 
vention that  makes  the  structure  of  the  program  more  visible.  Notice  also 
that  an  ELSE  statement  coming  inmediately  after  an  IF  belongs  to  that  same 
IF. 


The  simple  DO  structure  causes  a group  of  statements  to  be  executed 
as  if  they  were  a single  statement.  A common  usage  of  the  DO  structure 
is  with  the  IF  to  execute  a group  of  statements  when  a decision  is  made. 
The  DO  structure  looks  like  this: 
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DO; 


statement; 

statement; 

END; 

As  an  example  of  the  DO  structure  combined  with  an  IF: 

IF  this  is  a weekday 

THEN  DO; 

Get  dressed; 

Eat  breakfast; 

Go  to  school ; 

end; 

ELSE  go  back  to  sleep; 

The  DO  WHILE  structure  is  used  to  repeat  a group  of  statements  a 
controlled  number  of  times.  Its  form  is: 

DO  WHILE  condition; 
statement; 
statement; 

END; 

The  condition  is  a true/false  proposition  as  in  an  IF  structure. 

The  DO  WHILE  tests  the  condition  and  executes  the  statements  if  it  is  true, 
then  tests  it  again  and  reexecutes,  continuing  until  the  condition  proves 
to  be  false.  At  that  time,  it  passes  control  to  the  statement  following 
the  END.  As  an  example,  consider: 
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Take  out  your  work  book; 

DO  WHILE  there  are  problems  left 
in  today's  assignment; 

Solve  the  next  problem; 

Check  your  solution; 

END; 

Put  away  your  work  book; 

The  DO  FOR  structure  allows  a group  of  statements  to  be  repeatedly 
executed  based  upon  a set  of  values.  It  has  the  following  form. 

, DO  FOR  variable=values ; 

statement; 
statement; 

END; 

As  an  example  of  this  kind  of  control  structure,  consider: 

X = 0; 

DO  FOR  I » 1 to  31; 

IF  you  have  school  on  day  of 
month  "I" 

THEN  add  1 to  X; 

END; 

In  addition  to  the  above  control  structures,  conditions  and  state- 
ments can  be  joined  by  using  AND  and  OR.  In  this  way,  complex  conditions 
can  be  made  out  of  simple  ones.  They  have  their  usual  English  meanings. 

Although  there  are  other  logical  structures  that  can  be  added  to 
a PDL  to  account  for  peculiar  variations,  the  above  list  provides  suf- 
ficient flexibility  to  be  used  in  adequately  describing  most  situations. 
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5.3  STATE  TRANSITION  DIAGRAMS  FOR  LEXICAL  ANALYZERS 


The  lexical  analyzer  is  responsible  for  recognizing  the  elementary 
units  of  information,  known  as  tokens,  contained  in  the  source  data.  This 
source  can  be  thought  of  as  an  input  stream  consisting  of  individual  char- 
acters. These  characters  must  be  grouped  into  meaningful  units  (e.g., 
words)  before  the  parser  can  operate  on  them.  The  lexical  analysis  proce- 
dure is  basically  the  same  no  matter  what  input  data  are  assumed.  The 
character  groups,  however,  vary  widely  depending  upon  the  uses  of  the  input 
data.  To  identify  what  the  lexical  analysis  should  produce  is  a two  stage 
process.  First  a verbal  description  should  be  developed  of  the  various 
token  classes  and  literal  tokens  that  are  acceptable  as  input.  From  this 
verbal  description,  a state  transition  diagram  can  be  constructed  which 
allows  a simple,  yet  exact,  specification  of  the  token  recognition  process 
for  the  lexical  analyzer.  Consisting  of  a tree  structured  group  of  arcs 
and  nodes,  the  state-transition  diagram  accurately  describes  how  each  in- 
dividual character  in  the  input  stream  would  be  processed.  Several  state 
transition  diagrams  have  been  constructed  for  FLTOPS. 

To  understand  this  concept  more  exactly,  consider  the  simple  example 
discussed  in  the  sections  on  the  augmented  grammar  specification  technique. 
In  this  example,  the  sentence,  "THE  GIRL  LIKED  THE  DOG.",  is  a legal  state- 
ment. This  language  includes  one  token  class,  the  "word"  or  "identifier" 
(the  latter  term  is  more  commonly  used  in  the  context  of  programming  lan- 
guages). This  class  might  have  the  definition 

.ID  - Identifier.  Unlimited  in  length,  all 
characters  alphabetic. 

In  addition,  this  simple  language  uses  one  literal  token  which  needs  have 
no  class  name.  This  token  is  the  period. 

The  next  step  in  the  process  is  to  convert  the  definition  to  a state 
transition  diagram  which  defines  the  character-by-character  scanning  process 
to  be  performed  by  the  lexical  analyzer.  Twenty-eight  characters  are 
legal  for  this  particular  lexical  analyzer:  A,  B,  C,  D,  E,  F,  G,  H,  I, 


J,  K,  L,  M,  N,  0,  P,  Q,  R,  S,  T,  U,  V,  W,  X,  Y,  Z,  period  (.)  and  blank 

(JJ). 


Figure  8 shows  the  state  transition  diagram  for  our  example.  The 
lexical  analyzer  always  starts  in  state  zero.  One  state  transition  is 
made  for  each  character  removed  from  the  input  string.  Whenever  a purely 
final  state  is  reached,  a complete  token  has  been  scanned.  For  example, 
state  2 is  a final  state,  since  no  state  transitions  from  state  2 are 
indicated.  Note  that  state  2 is  also  identified  as  a legal  final  state  by 
the  presence  of  "F"  next  to  the  state  2 node.  State  1 is  a legal  final 
state  (it  has  an  "F"),  but  it  is  also  a possible  intermediate  state, 
since  one  or  more  state  transitions  from  state  1 are  possible.  When  the 
current  state  is  an  intermediate  state,  another  character  must  be  scanned. 
If  that  character  causes  a legal  state  transition,  the  process  continues. 
If  not,  then  either  a token  has  been  processed  (if  the  current  state  is 
also  a possible  final  state)  or  an  error  has  occurred. 

Notice  that  state  1 also  has  a state  name  ("ID").  This  indicates 
that  any  token  for  which  the  state- transition  process  terminates  at  state 
1 is  an  identifier. 

By  way  of  illustrating  the  meaning  of  this  state-transition  dia- 
gram, let  us  assume  that  the  first  four  tokens  (in  this  case,  ID's)  of  the 
sentence,  "THE  GIRL  LIKED  THE  DOG.",  have  already  been  recognized  and 
removed  from  the  input  stream.  Five  characters  remain:  blank  (Hi),  D, 

0,  G,  and  period  (.).  The  lexical  analyzer  starts  in  state  zero  and 
attempts  to  determine  whether  the  next  character  of  the  input  stream 
allows  a transition  from  its  current  state.  Since  the  next  character 
(blank),  is  recognizable  from  state  zero,  it  is  removed  from  the  input 
stream  and  the  lexical  analyzer  enters  the  state  indicated  by  the  arc 
associated  with  the  recognized  character  ()5).  In  this  case,  the  new 
state  is  again  state  zero  Since  the  initial  state  is  reentered,  the 
character  scanned  is  simply  ignored.  Thus,  in  this  case,  any  number  of 
blanks  between  tokens  are  ignored. 


I 


The  Input  stream  now  contains  four  characters  (DOG.)  and  the  cur- 
rent state  is  state  zero.  The  next  character  (D)  allows  a transition 
to  state  1 via  the  "alphabetic"  arc  labelled  A-Z.  The  character  scanned 
(0)  is  added  to  the  (presently  empty)  string  which  represents  the  token 
being  developed.  Thus,  the  token  is  now  "0",  the  input  stream  contains 
the  characters  "OG.",  and  the  lexical  analyzer  is  in  state  1. 

The  next  input  character  (0)  allows  a transition  from  state  1 
to  state  1 (the  second  A-Z  arc).  The  current  token  is  now  "DO",  and 
the  input  stream  is  "6.".  Similarly,  the  next  character  (G)  allows  a 
transition  via  the  same  arc,  and  the  token  and  input  strings  are  "DOG" 
and  respectively. 

Note  that  a period  (.)  does  not  allow  a legal  transition  from 
state  1.  Only  alphabetic  characters  can  be  processed  from  state  1. 

The  lexical  analyzer  is,  therefore,  finished.  It  returns  the  token 
"DOG",  and  leaves  the  input  stream  (now  ".")  for  processing  on  a sub- 
sequent call. 

Figure  8 has  one  remaining  property  which  deserves  comnent.  The 
arc  which  exits  and  enters  state  zero  causes  blanks  between  tokens  to  be 
ignored.  In  fact,  any  input  stream  entity  can  be  ignored,  and  therefore, 
not  passed  to  the  parser,  by  returning  to  state  zero  of  the  lexical  analy- 
zer. This  mechanism  is  commonly  used  to  handle  comments.  If,  for  ex- 
ample, the  format  for  a comnent  in  the  source  language  is  followed 

by  a character  string,  followed  by  "♦/'*,  the  lexical  analyzer  might  provide 
that  any  string  of  this  sort  causes  a return  to  state  zero.  Assuming 
that  a standard  lexical  analyzer  procedure  is  used,  this  results  in  a 
complete  restart  of  the  lexical  analyzer,  with  the  input  pointer  ad- 
vanced past  the  comnent. 
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State-transition  diagrams  are  actually  a little  more  sophisticated 
than  this,  but  this  example  is  correct  as  far  as  it  goes,  and  should  il- 
lustrate the  concept  of  lexical  analysis. 


5.4  TEXT  AND  GLOSSARIES 


In  addition  to  the  above  specification  mechanisms,  a small  amount 
of  supporting  text  and  glossaries  are  often  needed  to  completely  bring 
into  focus  the  concepts  furnished  by  the  design.  Textual  supplements 
serve  as  philosophical  aids  more  than  as  technical  support  for  the  design. 
Such  an  aid  is  necessary,  however,  for  a full  appreciation  of  the  design 
concepts,  and  to  bring  to  the  forefront  basic  assumptions  inherent  in  the 
design. 

Glossaries  add  still  another  dimension  to  the  design  specification. 
By  supplying  definitions  for  key  words  or  elements  used  in  the  design,  the 
augmented  grammar  is  made  more  readable  and  its  various  relationships  more 
understandable.  Definitions  are  not  supplied  for  those  elements  whose  use 
is  localized  and  whose  meanings  are  clearly  supplied  by  their  context. 


6.0  FORMAL  SPECIFICATION  OF  FLTOPS  DESIGN 


6.1  DISUCSSION  OF  DESIGN  CONCEPTS 

The  precompiler  design  consists  of  a number  of  components  that 
perform  the  functional  requirements  of  the  system.  Figure  9 schematically 
shows  the  functional  relationship  between  components  within  this  design. 
These  components  may  be  separated  into  several  categories:  the  input  pre- 
processor which  transforms  the  input  file  into  a format  easily  accessible 
by  precompiler  primitives;  the  lexical  analyzers  which  process  the  input, 
FCF  and  FORTRAN  data  for  token  recognition;  the  statement  processor  which 
performs  supervisory  control  over  all  functions;  the  functional  primitives 
that  perform  the  actual  processing  functions  of  the  system;  the  symbol 
table  storage  area  containing  all  values  to  be  used  in  the  customization 
process;  and  the  output  processor  which  writes  out  the  customized  FORTRAN 
code.  Each  of  these  areas  is  discussed  in  more  detail  below. 

6.1.1  Input  Preprocessor 

The  input  file  as  described  above  will  contain  hierarchic  data  and, 
possibly,  some  special  FCF  rules  under  development.  Because  of  the  prob- 
able frequency  with  which  the  input  data  will  be  referenced  in  the  FCF, 
an  input  preprocessor  would  provide  these  types  of  functions:  construct 
a map  of  the  hierarchic  form  of  the  data  for  speedy  access  and  construct 
a rule  name  table  of  all  special  FCF  rules  contained  in  input.  Both  of 
these  functions  are  intended  to  streamline  data  access  while  minimizing 
the  amount  of  scanning  necessary  to  locate  specific  input  requirements. 

6.1.2  Lexical  Analyzers 

Lexical  analysis  involves  the  analysis  of  the  input  stream  (a  stream 
of  individual  characters)  and  recognition  of  the  elementary  units  of  infor- 
mation, referred  to  as  tokens,  contained  therein.  The  precompiler  design 
uses  three  different  analyzers;  each  responsible  for  a separate  data  group 
input,  FCF  and  FORTRAN  type  data.  Each  lexical  analyzer  makes  the  last 
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token  recognized  available  to  the  precompiler  for  use  in  the  desired  fashion. 
Although  they  operate  on  different  data  streams  and  have  different  types 
of  tokens  that  they  recognize,  they  all  perform  similar  operations.  Table 
4 identifies  the  types  of  tokens  and  an  example  of  each  that  is  recognized 
by  each  lexical  analyzer. 

Several  things  should  be  noted  about  the  specific  lexical  analyzers. 
The  FCF  lexical  analyzer  recognizes  entire  FORTRAN  statements  by  the  ab- 
sence of  a P as  the  first  character  in  a line.  The  entire  FORTRAN  line  is 
processed  as  a single  token.  Upon  output,  however,  the  FORTRAN  lexical 
analyzer  performs  an  analysis  of  each  token  to  determine  if  it  should  be 
replaced.  Note  also  that  the  FORTRAN  lexical  analyzer  actually  consists 
of  two  analyzers:  one  that  performs  a special  analysis  of  FORTRAN  format 
statements,  and  the  other  for  all  other  statement  types.  Tokens  within  a 
FORTRAN  format  statement  are  the  individual  specifications,  e.g.,  5A4 
and  15HTHIS  IS  A TOKEN  and  ^ANOTHER  TOKEN*. 

6.1.3  FCF  Statement  Processor 

The  FCF  statement  processor  functions  as  the  supervisor  for  con- 
trolling the  overall  functions  of  the  precompiler.  It  serves  two  principal 
functions:  to  determine  syntactic  correctness  of  the  FCF,  issuing  error 
messages  if  appropriate;  and  to  dispatch  precompiler  functional  primitives 
in  accomplishing  the  semantic  intent  of  each  statement. 

In  controlling  the  precompiler  functions,  the  statement  processor 
can  be  in  any  one  of  three  functional  states.  These  functions  are  as 
follows: 

FULL  function:  all  precompiler  functional  primitives  are  operational; 

data  can  be  read  from  the  input  file  and  customized  FORTRAN  can  be 

output;  all  statements  are  checked  for  proper  syntax. 
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TABLE  A.  legal  TOICEN  CLASSES  IDENTIFIED  BY  LEXICAL  ANALYSIS 


DATA  TYPE 

IDENTIFIER 

NUMBER 

SIGNED_NUMBER 

STRING 

SPECIAL  SYMBOLS 

COMMENT 

blank 


DATA  TYPE 

IDENTIFIER 

NUMBER 

STRING 

LABEL 

SPECIAL  SYMBOLS 

COMMENT 

blank 


DATA  TYPE 
IDENTIFIER 
NUMBER 
STRING 

SPECIAL  SYMBOLS 
PLACE  HOLDER 
COf'WENT 

FORMAT  STATEMENT 


INPUT  LEXICAL  ANALYZER 
EXAMPLES 

EARTH  NON_ROTATING  Ml Oil 
7 8,3  9.61E-5 

-10  +8.45  -l.E+10 

'ANY  CHARACTERS  WITHIN  DELIMITERS* 

+ -*/**()=  .<  > 0 $ : ; 

/*  THIS  IS  A COMMENT  */ 
ignored 

FCF  LEXICAL  ANALYZER 
EXAMPLES 

ENTER  VARIABLE_X  X17  #C0MM0N 
7 26,32E5  18. 

'ANYTHING  BETWEEN  APOSTROPHES' 

$7  $15 

*+.**/#=()  , (3 

/*  COMMENTS  LOOK  LIKE  THIS  */ 
ignored 

FORTRAN  LEXICAL  ANALYZER 
EXAMPLES 

VARBLE  I X17 

7 18.3  9.E-5 

■ANY  CHARACTERS' 

+ -*/**=,()$ 

^A  #COMMON  <(SYMBOL 

any  statement  with  a C or  * or  $ in  column  1 

any  legal  FORTRAN  format;  individual  specifications 

are  treated  as  tokens,  e.g.,  FlO.4  and  1013  are  single 

tokens. 
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TEST  function;  all  precompiler  functional  primitives  are  opera- 
tional ejccept  those  relating  to  the  output  processor,  i,e.,  no 
customized  FORTRAN  is  output,  but  the  input  file  can  be  read  and 
the  FCF  checked  for  syntax. 

SYNTAX  function:  all  precompiler  functional  primitives  are  inopera- 
tive except  for  those  relating  to  syntax  checking  of  the  FCF.  The 
statement  processor  enters  the  syntax  function  mode  automatically 
whenever  a severe  error  occurs  or  whenever  a portion  of  the  FCF 
must  be  bypassed  because  of  a conditional  construct. 

Figure  10 contains  a simplified  schematic  describing  the  basic  analysis 
of  a token  by  the  statement  processor. 

Upon  receiving  the  next  token  from  the  FCF  lexical  analyzer,  the 
statement  processor  determines  the  syntactic  correctness  of  the  token  in 
the  context  of  its  location  within  the  FCF.  If  an  error  occurs,  an  appro- 
priate message  is  issued.  If  the  error  was  severe,  i.e.,  the  precompiler 
cannot  interpret  the  semantic  content  of  the  statement,  the  precompiler 
is  directed  to  provide  syntax  checking  only  for  the  remaining  FCF.  to  be 

checked.  In  the  case  of  a severe  error  associated  with  data  read  from 
the  input  file,  the  precompiler  FUNCTION  switch  is  reduced  to  TEST.  As 
a result,  the  user  can  continue  checking  the  input  file  for  additional 
errors,  but  will  receive  no  FORTRAN  ouptut.  After  insuring  that  the 
FCF  should  be  executed,  the  relevant  functions  accomplishing  the 
semantic  content  of  the  FCF  input  stream  are  executed.  FORTRAN  output 
is  produced  only  if  the  statement  processor  has  all  of  its  functional 
capability  enabled. 

6.1.4  Functional  Primitives 


n 


' 


Associated  with  each  FCF  control  statement  are  one  or  more  Tunc-  | 

tions  that,  when  executed  with  appropriate  parameters,  perform  the  actual  I’ 

II 
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Figure  10.  Basic  Operation  of  FCF  Statement  Processor 
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operations  implied  by  the  FCF  control  language.  Referred  to  as  the 
functional  primitives,  this  set  of  processes  performs  the  actual  semantic 
intent  of  the  FCF  control  statements.  They  are  known  as  primitives  be- 
cause, with  respect  to  the  precompiler,  they  perform  its  basic  functions.. 
These  operations  can  be  categorized  briefly  into  these  groups:  symbol 
table  access/modification  functions,  input  file  control  operations, 
statement  processor  control  functions,  arithmetic  operations,  boolean 
operations,  output  control  functions,  error  processing/recovery  processes, 
FCF  parsing  control  operations  and  processes  which  allow  computation  of 
precompile  time  values.  Each  category  performs  functions  related  to 
identifiable  portions  of  the  basic  precompiler  architecture.  Although 
all  functions  of  the  precompiler  can  be  thought  of  as  primitives,  those 
relating  to  input  and  output  have  been  identified  separately  for  reasons 
of  clarity  in  understanding. 

6.1.5  Symbol  Table  Storage 

Symbol  tables  play  a vital  role  in  the  precompiler  design.  There 
exists  in  the  FCF  control  language  a fairly  general  capability  for  the 
generation,  manipulation  and  use  of  the  symbol  tables  by  the  FCF  builder. 
Symbol  tables  can  be  thought  of  as  the  main  storage  area  for  the  precompiler. 
Once  a location  has  been  specified,  the  data  at  that  location  can  be  re- 
trieved/stored/modified by  appropriate  precompiler  primitive  functions. 

Implicit  in  the  FLTOPS  design  are  two  types  of  symbol  tables. 

Although  their  logical  structure  can  be  identical,  the  user  references  them 
differently.  The  first  is  the  classical  symbol  table  structure.  In  this 
type  of  symbol  table,  a value  string  is  stored/ retrieved/modi  fled  by  re- 
ference to  an  associated  symbol  name  in  a specified  table. 

In  the  second  type  of  symbol  table,  value  strings  are  stored/ re- 
trieved/modi fled  by  reference  to  a numbered  location  within  a specified 
table.  These  array  tables  are  similar  in  function  to  dimensioned 
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variables  in  other  programminq  languages  such  a;  FORTRAN  or  PL/1.  The 
critical  difference,  however,  is  that  as  in  the  classical  symbol  table 
structure,  the  value  string  can  be  of  arbitrary  length.  Although  an 
implementation  scheme  might  use  a different  approach,  the  subscripts 
of  the  specified  table  can  be  thought  of  as  being  a symbol;  i.e.,  they 
point  to  the  desired  table  entry.  Such  a parallelism  makes  the  logical 
structure  of  the  two  table  types  appear  the  same. 

Although  items  can  be  transferred  directly  from  input  to  output, 
the  majority  of  FCF  functions  directly  or  indirectly  use  information 
stored  by  the  user  in  the  symbol  tables.  Although  no  implementation 
procedure  is  implied,  it  will  be  useful  to  assume  that  symbol  tables  be 
logically  structured  as  shown  in  Figure  11.  This  structure  allows  an 
arbitrary  list  of  symbol  tables,  each  identifiable  by  table  name.  Cach 
table  may  contain  an  arbitrary  list  of  symbol  entries,  each  identifiable 
by  sumbol  name.  Table  records  and  symbol  records  are  assumed  to  be  chained 
together  in  some  fashion  to  allow  a search  for  the  desired  table  and  svmbol . 
Associated  with  each  symbol  entry  is  a "value."  The  value  is  a character 
string  of  logically  unlimited  length  and  content.  The  value  string  may 
have  length  zero  (i.e.,  may  be  a null  string). 

In  addition  to  providing  a general  purpose  symbol  table  capability 
for  use  by  the  FCF  builder,  FLTOPS  symbol  tables  also  control  certain 
oata-driven  functions  of  the  precompiler.  Specifically,  the  FLTOPS  pass 
1 and  pass  2 FORTRAN  string  replacement  functions  are  controlled  by  the 
symbol  tables  whose  names  arp  "PASSl"  and  "PASS2".  The  precise  mechanism 
for  this  is  discussed  in  t.tie  ne^t  srction  on  the  output  processor  As  ^ 
simple  example,  though,  consider  again  the  symbol  tables  of  Figure  11. 

Notice  that  the  "PASSl"  table  contains  an  entry  for  the  symbol  "PI"  with 
value  "3.14159".  The  value  represents,  in  this  case,  a replacement  string. 
While  this  entry  remains  in  the  PASSl  table  and  the  precompiler  is  active 
and  in  pass  1,  any  occurrence  of  the  variable  name  "PI"  in  the  FORTRAN 
gener'ated  by  the  precompiler  will  result  in  substitution  of  the  value 
3.14159. 
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6,1,6  Output  Processor 

Except  for  messages  and  listings  all  output  from  the  precompiler  is 
passed  through  an  output  processor.  This  processor  performs  several  functions: 

|. 

' outputs  values  passed  to  it  in  one  of  several  modes,  currently 

either  DATA  or  FORTRAN; 

performs  a lexical  analysis  of  each  FORTRAN  statement; 

performs  substitutions  of  FORTRAN  tokens  from  the  PASSl  and 
PASS2  symbol  tables; 

insures  that  each  FORTRAN  statement  complies  with  proper  card 
image  format  and  that  sequence  numbers,  if  desired,  are  in- 
serted; and 

writes  out  end  of  file  or  end  of  record  marks  as  instructed. 

In  the  DATA  output  mode,  the  output  processor  simply  transfers  data 
passed  to  it  to  the  output  file.  This  data  is  stored  in  an  output  buffer 
until  a statement  terminator  is  encountered,  at  which  point  the  actual  out- 
put occurs.  No  substitutions  are  made,  from  either  the  PASSl  or  PASS2 
tables  for  any  data  output  in  this  mode, 

FORTRAN  comment  cards  are  treated  in  much  the  same  manrer  as  items 
output  in  the  DATA  mode.  There  are  no  substitutions  from  either  the  PASSl 
or  PASS2  tables.  Actual  output  occurs  upon  output  of  a statement  terminator. 

As  each  FORTRAN  statement  is  encountered  in  the  FCF,  it  is  passed  to 
the  output  processor.  If  the  PASSl  table  is  non-empty,  the  output  processor 
calls  upon  the  FORTRAN  lexical  analyzer  to  perform  a lexical  analysis  of 
the  statement.  Each  token  recognized  by  the  lexical  analyzer  is  matched 
against  those  symbols  appearing  in  the  PASSl  symbol  table.  If  a match 
occurs,  the  symbol  table  value  is  substituted  for  the  token  before  it  is 
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stored  in  an  output  buffer.  Substitutions  of  this  type  can  be  recursive. 

The  output  processor  guards  against  instances  of  infinite  recursion  by 
allowing  only  a fixed  number  of  replacements  for  any  one  token  in  a FORTRAN 
statement.  Once  the  last  token  of  the  statement  has  been  processed,  the 
output  buffer  is  written  to  a temporary  file  referred  to  as  the  PASSl 
output  file. 

Upon  completion  of  the  FCF,  the  precompiler  checks  to  see  if  the 
PASS2  table  is  non-empty.  If  so,  the  precompiler  continues  processing, 
otherwise  it  is  finished.  Referred  to  as  PASS2,  the  precompiler  accesses 
the  PASSl  output  file  which  contains  output  from  PASS2  (no  FCF  control 
statements  appear  here).  A lexical  analysis  is  performed  on  each  FORTRAN 
statement,  but  in  this  case,  substitutions  are  made  from  the  PASS2  symbol 
table.  Note  that  no  substitutions  are  made  on  data  which  was  output  in 
the  DATA  mode  during  PASSl. 

Note  that  since  no  FCF  control  statements  are  executed,  PASS2  sub- 
stitution is  global  in  scope.  This  may  be  extremely  useful  for  insertions 
of  common  blocks  and  dimension  or  data  statements  whose  complete  structure 
may  not  be  known  until  some  point  after  their  required  insertion  point 
has  been  processed.  Extra  processing  is  required,  however,  to  accomplish 
this  extra  substitution  and  some  care  should  be  exercised  in  its  use. 

Once  the  last  token  of  each  statement  has  been  processed  during 
PASS2,  the  precompiler  writes  the  statement  out  to  what  is  known  as  the 
PASS2  output  file. 

Whether  PASS2  substitution  actually  occurs  or  not,  all  FORTRAN 
statements  are  checked  to  insure  that  proper  FORTRAN  card  image  syntax 
is  maintained.  Data  output  in  the  DATA  mode  is  left  unaltered.  The  input  to 
the  compiler  is  contained  on  the  file  referred  to  in  this  document  as 
PASS2,  regardless  of  whether  or  not  PASS2  table  substitutions  occurred. 

The  output  processor  is  not  operational  if  the  statement  processor 
is  not  at  FULL  function  capability. 
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6.2  SPECIFICATION  OF  FUNCTIONAL  PRIMITIVES 

FLTOPS  PRIMITIVES 

/•**•***•••*••*•*•*•*•*****••*•*******•••*****••*******/ 

/*  SPECIAL  SriBOLS  USEU  TO  INDICATE  CONTROL  STRUCTURE  */ 

/.***•«•****•***«*******«***•*•*****««««****•«*•*****•«/ 


S PERFORM  THE  FOLLOWING  UNIT  ZERO  OR  MQRE  TIMES,  AS  LONG  AS  IT  CONTINUES 

TO  SUCCEED.  SUCCESS  IS  DEFINED  AS  A TRUE  VALUE  OF  THE 
FCF  PARSING  TRUE  FALSE  INDICATOR. 


(...)  CONSIDER  THE  ELEMENTS  WITHIN  PARENTHESES  TO  BE  A SINGLE  UNIT,  WHICH  CAN 
SUCCEED  OR  FAIL. 


THIS  SYMBOL  IS  A LOGICAL  "OR”  SYMBOL.  IT  IMPLIES  THE  EXISTENCE  OF  MORE 
THAN  ONE  ALTERNATIVE,  ANY  ONE  OF  WHICH  IS  SUFFICIENT  TO  CAUSE  THE  LARGE 
UNIT  (RULE  OR  PARENTHETICAL  EXPRESSION)  TO  BE  CONSIDERED  "SUCCESSFUL". 
THUS, 

( • ' ) 

INDICATES  THE  EXISTENCE  OF  THREE  ALTERNATIVES.  THE  ELEMENTS  OF  THE  FIRST 
alternative  are  APPLIED  UNTIL  A "SYNTACTIC"  ELEMENT  (ONE  WHOSE  PRIMITIVE 
DEFINITION  SETS  THE  F C F _P A R S I NG.TRUE _F AL SE _I  ND IC AT OR ) IS  FOUND.  IF  THAT 
ELEMENT  IS  "SUCCESS FUL"7  THE  ALTERNATIVE  IS  USED  AND  ANY  SUBSEQUENT 
ELEMENTS  OF  THAT  ALTERNATIVE  ARE  APPLIED.  IF  THE  ELEMENT  FAILS,  THE  NEXT 
ALTERNATIVE  (AFTER  THE  OR  SYMBOL,  "!")  IS  APPLIED  IN  THE  SAME  MANNER. 

IF  ANY  ALTERNATIVE  IS  "SUCCESSFUL",  THE  OVERALL  PARENTHETICAL  EXPRESSION 
IS  ALSO  "SUCCESSFUL",  OTHERWISE  NOT. 


PERFORM  STRING  CONCATENATION 

/*  SPECIAL  SYMBOLS  USED  AS  ARGUMENTS  OF  PRIMITIVES  */ 

/*•*************************************************/ 


* THIS  SYMBOL  REFERS  TO  FC F_PREV lOUS.SYMBOL,  THE  FCF  SYMBOL  LAST  PARSED 

BY  THE  PRECOMPILER. 


**  THIS  SYMBOL  REFERS  TO  T EMP OR  A R Y _S T R I N6  , A UTILITY  VARIABLE  WHICH  MAY 
CONTAIN  A CHARACTER  STRING  OF  ARBITRARY  LENGTH  AND  CONTENT. 


I 

I 
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FLTOPS  PRI?1ITH/ES 


/*  INITIALIZATION  *! 

/******************/ 


.PREPROCESS_INPUT_FILE: 


/*  THIS  PROCESS  HAS  NO  LOGICAL  FUNCTION^  3UT  IS  INCLUDED  HERE  *! 
/*  IN  ORDER  TO  CALL  ATTENTION  TO  THE  PROBABLE  EXISTENCE  OF  AN  */ 
/*  INPUT  FILE  PREPROCESSING  OPERATION  WHICH:  */ 
/*  (A)  CONVERTS  THE  INPUT  INFORMATION  FROM  SEQUENTIAL  TO  */ 
/*  LIST  FORM,  OR  CONSTRUCTS  AN  INTERNAL  (HIERARCHIC)  */ 
/*  MAP  OF  THE  SEQUENTIAL  INPUT  INFORMATION,  AND  */ 
/*  (3)  SCANS  ANY  FCF  INFORMATION  IN  THE  INPUT  FILE  IN  */ 
/*  ORDER  TO  CONSTRUCT  A RULE  NAME  TABLE.  */ 
/*  THESE  OPERATIONS  ARE  THOUGHT  TO  BE  APPROPRIATE  FOR  REASONS  */ 
/*  OF  EFFICIENCY,  BUT  DO  NOT  CAUSE  DATA  TRANSFORMATIONS  WHICH  */ 
/*  IMPACT  THE  FLTOPS  FUNCTIONAL  DEFINITION. 


END  .PREPROCESS_INPUT_FILE; 


/*  FCF  TO<EN  RECOGNITION  OPERATIONS 


.IDENTIFIER: 

/*  ATTEMPT  TO  RECOGNIZE  NEXT  FCF  TOKEN  AS  IDENTIFIER. 

IF  FCF_SYMBOL  CLASS  RETURNED  ON  PREVIOUS  INVOCATION  OF  FCF  LEXICAL 

ANALYZER  IS  'IDENTIFIER' 

THEN  DO; 

CALL  FCF  LEXICAL_ANALYZER; 

SET  FCF_PARSING_TRUE_FALSE_INDICATOR  TO  'TRUE'; 

END; 

ELSE  SET  FCF_PARSING_TRUE.FALSE_INOIC ATOR  TO  'FALSE'; 

END  .IDENTIFIER; 


.NUMBER  : 

/** 

/* 

/** 

IF 


END 


*********************************************•********'*******/ 
ATTEMPT  TO  RECOGNIZE  NEXT  FCF  TOKEN  AS  NUMBER.  */ 

*******************************************«*****************/ 
FCF.SYMSOL  CLASS  RETURNED  ON  PREVIOUS  INVOCATION  OF  FCF  LEXICAL 

ANALYZER  IS  'NUMBER' 

THEN  DO; 

CALL  FCF_LEXICAL_ANALYZER; 

SET  FCF_PARSING_TRUE_FALSE_INDICATOR  TO  'TRUE'; 

END; 

ELSE  SET  FCF_PARSI.NG_TRUE_FALSE_INOICATOR  TO  'FALSE'; 

.NUMBER; 
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FLTOPS  PRI'^ITIVES 


.STRING: 

/***••*«•**•**********•*********  ***•#•*«*«,***«****•*•***  *****«*•/ 

/*  ATTEJnPT  T3  RECOGNIZE  NEXT  FCF  TOKEN  AS  CHARACTER  STRING  */ 

/*  DELINITEO  BT  SINGLE  QUOTATION  MARKS.  */ 

/***•*#****•**********************•*** •*****************i^«******/ 


IF  FCF_SYMBOL_CLASS  RETURNED  ON  PREVIOUS  INVOCATION  OF  FCF  LEXICAL 

analyzer  IS  'STRING* 

THEN  DO; 

CALL  FCF  LEXICAL.ANALYZER; 

SET  FCF  PARSING  TRUE  FALSE  INDICATOR  TO  'TRUE'; 

END; 

else  set  FCF_PARSInG_TRUE_FALSE_INDIC ATOR  TO  'FALSE'; 

END  .STRING; 


/*  ANY  STRING  LITERAL,  BRACKETED  BY  QUOTATION  MARKS  */ 


/*  ATTEMPT  TO  RECOGNIZE  NEXT  FCF  TOKEN  AS  SPECIFIED  LITERAL  */ 

/*  STRING  (E.6.  "EXAMPLE").  •/ 

/*****•**•«******•******•********************«***********«**••**/ 

IF  FCF_SYM90L  RETURNED  ON  PREVIOUS  INVOCATION  OF  FCF  LEXICAL  ANALYZER  IS 

IDENTICAL  TO  LITERAL  STRING 

THEN  DO; 

CALL  FCF  LEXICAL.ANALYZER; 

SET  FCF  PARSING  TRUE  FALSE  INDICATOR  TO  'TRUE'; 

END; 

ELSE  SET  FCF  PARSING  TRUE  FALSE  INDICATOR  TO  'FALSE'; 

END 

.LABEL: 

/•**********************•********************************•*****•/ 

/*  ATTEMPT  TO  RECOGNIZE  NEXT  FCF  TOKEN  AS  SYMBOL  FOR  ABSTRACT  */ 

/*  FORTRAN  STATEMENT  LABEL  (E.G.,  S1).  */ 

/**■^t**t******■^^*■^t*■»**■^^■******^^***^Ht»**■»^^********^^»»»»i^*»***»t***»»/ 

IF  FCF  SYMBOL  CLASS  RETURNED  ON  PREVIOUS  INVOCATION  OF  FCF  LEXICAL 

ANALYZER  IS  'LABEL' 

THEN  DO; 

CALL  FCF.LEXICAL.ANALYZER; 

SET  FCF.PARSING.TRUE.FALSE.INDICATOR  TO  'TRUE'; 

END; 

ELSE  SET  FCF_PARSIN6.TRUE_FALSE_INDIC ATOR  TO  'FALSE'; 

END  .LABEL; 
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fLTOPS  PRIMITIVES 


,PbE<  (ArtfiUMENT) 

/•**•**«*•****•******************»*••***«***««***•***.*««*«««•«*«/ 

/*  LOOK  AHEAD  TO  SEE  IF  NEXT  TOKEN  PARSED  WILL  BE  IDENTICAL  TO  «/ 
/•  THE  LITERAL  STRING  PASSED  AS  THE  ARGUMENT.  NOTE:  THERE  MAY  */ 
/*  BE  ONE  OR  MORE  ITEMS  IN  THE  ARGUMENT  LIST  SEPARATED  BY  CR  *l 
/*  (!)  SYMBOLS  */ 

/***••**••***••*******«***********•***«*«****•***•*«*****«•****••/ 
COMPARE  EACH  TOKEN  IN  ARGUMENT  LIST  WITH  FCF  SYMBOL; 

IF  ANY  ONE  IS  EQUIVALENT  TO  FCF^SYMBOL  THEN 

SET  FCF  PARSING_TRUE_F ALSE'inDICATOR  TO  TRUE  ; 

ELSE  SET  FCF_PARSIN6_TRUE_FALSE  INDICATOR  TO  FALSE  ; 

END  .PEEK 


.FORTRAN: 


/*  ANY  COMPLETE  FORTRAN  STATEMENT  */ 


/*  ATTEMPT  TO  RECOGNIZE  NEXT  FCF  TOKEN  AS  A FORTRAN  STATEMENT.  */ 
/*  FORTRAN  STATEMENTS  ARE  IDENTIFIED  BY  ABSENCE  OF  "P“  IN  •/ 

/*  COLUMN  1.  IF  THERE  ARE  CONTINUATION  CARDS,  THE  ENTIRE  */ 

/•  FORTRAN  STATEMENT  IS  CONCATENATED  INTO  ONE  STRING.  */ 

/****«****•********•*******************•**•*********«*****•***•*/ 
IF  FCF  SYMBOL.CLASS  RETURNED  ON  PREVIOUS  INVOCATION  OF  FCF  LEXICAL 

ANALYZER  IS  'FORTRAN* 

THEN  DO; 

CALL  FCF_LEXICAL_ANALYZER; 

SET  FCF_PARSIN6_TRUE^FALSE_1NOICATOR  TO  'TRUE'; 

END; 

ELSE  SET  FCF.PARSING  TRUE  FALSE  INDICATOR  TO  'FALSE*; 

END  .FORTRAN; 


I **  / 

/*  SYMBOL  TABLE  OPERATIONS  */ 


.FINO_TABLE  (ARGUMENT): 

/*  FIND  FIRST  SYMBOL  OF  SPECIFIED  TABLE.  IF  NECESSARY,  BUILD  */ 

/*  NEW  TABLE.  */ 

SEARCH  LIST  OF  SYMBOL  TABLE  NAMES  FOR  ONE  IDENTICAL  TO  ARGUMENT; 

IF  SEARCH  WAS  SUCCESSFUL  THEN  DO 

DO  WHILE  THIS  TABLE  POINTS  TO  AN  EQUIVALENCED  TABLE; 

UPDATE  TABLE  POINTER  TO  THE  EQUIVALENCED  TABLE  VALUE; 

END; 

SET  SYMBOL  TABLE  POINTER  TO  POINT  TO  FIRST  SYMBOL  OF  THIS  TABLE; 

END; 

/*  NOTE  THAT  SYMBOL  MAY  BE  NULL  */ 

ELSE  DO; 

ADD  NEW  TABLE  TO  LIST,  USING  NAME  PASSED  AS  ARGUMENT; 

SET  SYMBOL_TABLE_POINTER  TO  POINT  TO  (NULL)  FIRST  SYMBOL  OF  TABLE; 
END; 

SET  CURRENT.TABLE.NAME  TO  ARGUMENT; 

END  .FIND, TABLE; 
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FLTOPS  PRI'IITIVES 


.FI'^O  OR  ENTER  SY'IBOL  (ARGUMENT): 

~/*;*************************** ******************** **•**•***««***/ 

/•  SEARCN  TABLE  FROM  CURRENT  SYMBOL  DOWN,  LOOKING  FOR  */ 

/*  SPECIFIED  SYMBOL.  IF  NOT  FOUND,  ADD  NEJ  ENTRY.  */ 

/*•*****•**********************•**«**********•*•*•*******#**•*•*/ 


BEGINNING  AT  CURRENT  SVM80L_TABLE_P0INTER  LOCATION,  SEARCH  LIST  OF  SYMBOL 

“names  for  name  identical  to  ARGUMENT; 

IF  SEARCH  WAS  SUCCESSFUL 

THEN  SET  SYMBOL  TABLE  POINTER  TO  POINT  TO  FOUND  SYMBOL; 

ELSE  DO; 

ADO  NEW  SYMBOL  TO  LIST,  USING  NAME  PASSED  AS  ARGUMENT; 

SET  SYMBOL  TABLE  POINTER  TO  POINT  TO  NEWLY  ADDED  SYMBOL; 

END; 

END  .FIND_OR_ENTER_SYMBOL; 


.TEST  FOR  SYMBOL  (ARGUMENT): 

'/**;**•*•* ************************************** ****«***«***««•*/ 

/*  SEARCH  TABLE  FROM  CURRENT  SYMBOL  DOWN,  LOOKING  FOR  */ 

/♦SPECIFIED  SYMBOL.  IF  MOT  FOUND,  INDICATE  FAILURE.  */ 


/*•***********•*************************************************/ 

BEGINNING  AT  CURRENT  SYMBOL  TABLE  POINTER  LOCATION,  SEARCH  LIST  OF  SYMBOL 

“names  for  name  identical  to  ARGUMENT; 

IF  SEARCH  WAS  SUCCESSFUL 
THEN  DO; 

SET  SYMB0L_TA8LE_P0INTER  TO  POINT  TO  FOUND  SYMBOL; 

SET  OPERATrON_TRUE_FALSE_I'IDICATOR  TO  'TRUE'; 

END; 

ELSE  SET  OPERATION_TRUE_FALSE_INOICATOR  TO  'FALSE'; 

END  .TEST_F0R_SYM30L;“ 

.ENTER_VALUE  (ARGUMENT): 

/**•*•*•********************************«*****************«*****/ 


/•  ENTER  SPECIFIED  VALUE  AT  CURRENT  SYMBOL_TABLE_POINTER  */ 

/•  LOCATION.  */ 

/***************************************************************/ 


CONSIDER  SYMBOL  ENTRY  TO  WHICH  SYMB0L_TA8LE_P0INTER  CURRENTLY  POINTS; 
REPLACE  VALUE  FIELD  OF  THIS  SYMBOL  ENTRY  WITH  STRING  PASSED  AS  ARGUMENT; 
END  .£NTER_VALUE; 
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FLTOPS  PRIMITIVES 


MESSAGE  (MESSAGE,  SPECIAL  INSTRUCTIONS): 


FLTOPS  PRliil  I IVtS 


.GET  VALUE  (A;<GUMENT)  ; 

/«***#****«***«*********«*******•«****************•***#**«*«««/ 

/*  STORE  IN  THE  PLACE  INDICATED  BY  THE  ARGUMENT  THE  VALUE  */ 

/*  STRING  ASSOCIATED  WITH  SYMBOL  TABLE  ENTRY  IN  THE  LOCATION  */ 

/*  CURRENTLY  POINTED  TO  BY  SYM30L_TABLE_PCINTER.  */ 

/***********'**'*******•******************************'****•**'***/ 
CONSIDER  SYMBOL  ENTRY  TO  WHICH  S YMBOL.T A BL E _PO IN TE R CURRENTLY  POINTS; 
IF  THERE  EXISTS  A VALUE  ENTRY  FOR  THIS  SYMBOL 

THEN  COPY  VALUE  FIELD  INTO  LOCATION  INDICATED  BY  ARGUMENT; 

ELSE  ENTER  NULL  STRING  INTO  LOCATION  INDICATED  3Y  ARGUMENT; 

END  .6ET_VALUE; 


.CATENATE.VALUE  (ARGUMENT): 

/**•*********************************************★**** *****1 

APPEND  SPECIFIED  STRING  ONTO  VALUE  FIELD  OF  SYMBOL  TABLE 
/*  ENTRY  POINTED  TO  BY  SYMBOL_TABLE_POINTFR . 


• */ 

*/ 

*/ 


CONSIDER  SYMBOL  ENTRY  TO  WHICH  S YMBOL.T A 9L E _PO IN TE R CURRENTLY  POINTS; 
CATENATE  STRING  PASSED  AS  ARGUMENT  ONTO  END  OF  VALUE  FIELD  OF  THIS  ENTRY; 
END  .CATENATE_VALUE; 


.REPLACE.STRING  (STRINGl ,STRING2,NUMBER ) 


*/ 

*/ 

'*/ 


/*  REPLACES  NUMBER  OCCURRENCES  OF  STRING!  WITHIN 
/*  ANOTHER  STRING  WITH  STRINGS 

/*********«*•*•«*•**«*****★**«****«***«*****«******* 

GET  VALUE  POINTED  AT  BY  SYMBOL_T A0LE_POI NT ER  ; 

SET  1=0; 

DO  WHILE  I < NUMBER; 

INCREMENT  I; 

IF  STRING!  IS  NULL  THEN  CATENATE  STRING2  ONTO  BEGINNING  OF  VALUE; 
ELSE  DO; 

SCAN  VALUE  TO  FIND  FIRST  OCCURRENCE  OF  STRING!; 

IF  MATCH  OCCURS 

THEN  IF  STRINGS  IS  NULL 

THEN  DELETE  STRING!  FROM  VALUE; 

ELSE  REPLACE  STRING!  WITH  STRINGS; 

ELSE  SET  I = NUMBER; 

END; 

END; 

ENTER  VALUE  INTO  LOCATION  POINTED  AT  BY  SYMBOL  _T  A8  LE  _P  0 1 tt  T E R ; 

END  .R£PLACE_STRIN6; 


.INDEX  (STRING, SUBSTRING, START  PCS)  : 

/«******«**«***«*«****************«***«*««***«***««***«**«*« ^ 

/*  DETERMINE  STARTING  POSITION  Of  SUBSTRING  WITHIN  A STRING 


SCAN  STRING  FOR  THE  FIRST  OCCURRENCE  OF  SUBSTRING; 

IF  SUBSTRING  WAS  FOUND  IN  STRING  THEN  SET  START_POS  TO  THE 
CHARACTER  POSITION  IN  STRING  WHERE  SUBSTRING  BEGINS; 
ELSE  SET  START_POS  TO  ZERO; 

END  .INDEX; 


-*/ 

*/ 

'*/ 
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.LEMSTH  (STRING, STRI,'4G_LENGTH)  : 

/*•«**•**•*****•;****•********•******«••****************•*•****•/ 

/«  DETERMINE  THE  NUMBERS  OF  CHARACTERS  IN  A STRING  •/ 




COUNT  THE  NUMBER  OF  CHARACTERS  IN  STRING  AND  RETURN  THE  RESULT  IN 

string.length; 

END  .LENGTH; 


.DELETE  ENTRY; 


/*  DELETE  ENTIRE  ENTRY  AT  CURRENT  SYMBOL  TABLE  POINTER  */ 

/*  LOCATION.  “ “ */ 

/*•************«***«*«****«******•***********************••*****/ 
DELETE  SYMBOL  ENTRY  TO  WHICH  SYMBOL  TABLE  POINTER  CURRENTLY  POINTS; 
UPDATE  POINTERS  TO  MAINTAIN  TABLE  INTEGRITY; 

END  .OELETE_ENTRY; 


.SAVE_POINTER; 

/*•******«**•*****«*****•*******«****•*******•**«*****«•**•«****/ 

/*  STORE  CURRENT  S Y M80L_T A 8LE _?0 I N T ER  LOCATION  FOR  LATER  USE.  */ 

/***•****«*****•**•****«*****;*******«•*«********•**«***«•**•«•*/ 

PUSH  VALUE  OF  SYMBOL  TABLE_POI NTER  ONTO  TOP  OF  SAVED  POINTER  STACK; 
END  .SAVE^POINTER; 


• RESTORE  POINTER; 


/*  RESTORE  PREVIOUS  VALUE  OF  S Y MB OL_T ABL E_PO I N TE R LOCATION.  */ 

/*******•«*************************;*«***;**«********«*******•«./ 

REMOVE  TOP  VALUE  IN  SAVEO_POIMTER_STACK; 


SET  SYMBOL  TABLE  POINTER  TO  THIS  VALUE; 
END  .RESTORE_POINTER; 


fltops  prinitives 


r 


.SJSSTRIMG  (STRIMG.I*»,STRING_OUT,START_POS,LENGTH)  : 

/•a************************************* ****** ***********************/ 

/•  PERFORMS  SUBSTRING  EXTRACTION  FROM  STRING.IN  TO  STRING.OUT.  */ 

/♦  SUBSTRING  BEGINS  AT  CHARACTER  POSITION  START  POS  AND  CONTAINS  */ 

/*  A MAXIMUM  OF  LENGTH  CHARACTERS.  IF  LENGTH  PARAMETER  IS  NOT  */ 

‘ /*  PRESENT,  SUBSTRING  CONTAINS  ALL  CHARACTERS  TO  RIGHT  OF  START_POS  */ 

/A*************************'***********'****'*********'***'***'************/ 

SET  STRING  OUT  = NULL; 

IF  OPTIONAL  LENGTH  PARAMETER  IS  IN  CALLING  SEQUENCE 
' THEN  DO; 

IF  LENGTH  > 0 
THEN  DO; 

STARTING  WITH  CHARACTER  POSITION  START.POS; 

COPY  A MAXIMUM  OF  LENGTH  CHARACTERS  FROM  STRING.IN  TO  STRING_OUT; 
END; 

i ELSE  RETURN; 

i ELSE  DO; 

STARTING  WITH  CHARACTER  POSITION  START_POS; 
i COPY  ALL  CHARACTERS  TO  THE  RIGHT  FROM  STRING_IN  TO  STRING.OUT; 

i END; 

I END  .SUBSTRING; 

! 

j .FIND  BY  SUBSCRIPT  (ARGUMENT): 

~/ *********  ****************************** 

/*  PERFORMS  ABSOLUTE  POINTER  POSITIONING 
/*************************************** 

LOCATE  THE  TABLE  VALUE  INDICATED  BY  THE 
SET  THE  SYMBOL_TABLE_POlNTER  TO  POINT  AT 
END  .FIND  BY  SUBSCRIPT 


.C0MPUTE_TA3LE_P0SITI0N: 

/*************************************** 
/*  USES  STANDARD  FORTRAN  ARRAY  POSITION 
/*  POSITION  OF  A SPECIFIED  ARRAY  ENTRY. 
/*  INFORMATION  ON  THE  SIZE  OF  TABLE  SUBS 
/»  CORRESPONDING  DEFINE  STATEMENT. 
/*************************************** 
SET  SUBSCRI?T_NUM8ER  = STACX_SIZE-1 ; 

SET  ARRAY. POSITION  =0 

DO  WHILE  SU3SCRIPT.NUM3ER  >=  0 ; 

POP  TO?  element'from  array.stack  and 
IF  SUBSCRIPT.NUMBER  a 0 

THEN  ADO  TEMPORARY.VALUE  TO  ARRAY. 
ELSE  DO; 

RETRIEVE  VALUE  FOR  SUBSCRIPT  NUMB 
OF  CURRENT.TA3LE.NAME; 
SAVE  THIS  VALUE  IN  SUBS CR IPT.VALU 
SET  ARRAY  POSITION  = SJBSCRIPT.VA 

TEMPORARY. 

END; 

DECREMENT  SUBSCRIPT  NUMBER  BY  1; 

* END; 

END  . COMPUTE. TABLE.POSITION; 


WITHIN  A TABLE  */ 
*****************/ 
NUMBER  IN  ARGUMENT; 
THIS  VALUE; 


*****************************/ 

COMPUTATIONS  TO  COMPUTE  THE  */ 
THE  TABLE  HEADER  INCLUDES  */ 
CRIPTS  AS  PROVIDED  BY  THE  */ 

*/ 

*****************************/ 


SAVE  IN  TEMPORARY.VALUE; 
POSITION; 

ER  FROM  TABLE.HEAOER 
E; 

LUE  * (ARRAY  POSITION* 

value-1); 
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.ARRAY 


.^ULL 


.SETJP 


SETUP  (TABLE  NAME) 

************************************************** ***«**««•/ 
/*  PERFORMS  INITIALIZATION  FOR  TABLES  REFERENCED  BY  SUBSCRIPT  */ 
/*•**••*«***********•*****•*•********«**«**«**«««****#***«**••*/ 

.FIN0_TAJLE( TABLE. NAME) 

SAVE  ARRAY.STACK  CONTENTS  IN  TABLE.HEADER  Of  TABLE  TABLE.NAME; 
DELETE  ALL'eNTRIES  ALREADY  IN  TABLE; 

.END  ARRAY.SETUP; 


OUT  TABLE  (NAME); 

/* •7****** ******•***••*********•**••*****«************«*«*****•*/ 

/•  REMOVE  ANY  TABLE  EOUIVALENCE  AND  DIMENSIONS  FOR  TABLE  NAME  •/ 

/•*«*****«****«•**«**********«*******«*******••****•*•******••**/ 

IF  SYMBOL  TABLE  NAME  IS  NON-EMPTW  THEN  DO; 

WRITE  OUT  warning  MESSAGE  INDICATING  THE  TABLE  IS  BEING  CLEARED; 
CLEAR  TABLE  OF  ALL  ENTRIES; 

END; 

If  TABLE  NAME  IS  EOUIVALENCED  TO  ABOTHER  TABLE  THEN  REMOVE  THE 
EOUIVALENCE; 

IF  TABLE  NAME  IS  DIMENSIONED  THEN  REMOVE  ITS  DIMENSIONS; 

END  .NULL.OUT.TABLE ; 


_T  ABLE.EOUIVALENCE : 

/*****•*******•***••***•***********«««*******«************«««***/ 

/*  EOUIVALENCE  ONE  TABLE  NAME  WITH  ANOTHER  SO  THAT  EITHER  NAME  */ 


/•  REFERENCES  THE  SAME  GROUP  OF  SYMBOL  TABLE  ENTRIES  */ 

/«•«**•*****•••****«******•*******•****•««**«******«********«***/ 


IF  TABLE  IDENTIFED  BY  OE F I NE _T A 3 LE _N AM E ALREADY  EXISTS  THEN 

IF  IT  HAS  ENTRIES  OF  ITS  OWN  (iTe.  IT  IS  A REAL  TABLE  AND  NOT 
"RtViOUSLY  EOUIVALENCED  TO  ANOTHER  TABLE  ) THEN  WRITE  AN 
ERROR  MESSAGE  INDICATING  THAT  THIS  IS  AN  ILLEGAL  EQUIVALENCE; 
IF  EOUIVALENCED  table  name  HAS  BEEN  PREVIOUSLY  EOUIVALFNCED  TO 

DEFINE. TABLE.NAME  THEN  WRITE  OUT  SEVERE  ERROR  MESSAGE  INDICATING 
THE  LINK; 

ELSE  SET  US  LINK  THAT  INSURES  A REFERENCE  TO  DEFINE. TABLE  NAME  “OINTS 
TO  EOUIVALENCED. TABLE.NAME; 

END  .SETUP  TABLE.EQuFvALENCE; 
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/•«**«*****•****••••**«**•*«*#**•«*••««**«*•*•«•***/ 

/•  INPUT  FILE  LEXICAL  ANALYZER  CONTROL  OPERATIONS  */ 

/*#*******•*****«*******•*«***«***•**«•***•*•«***•*/ 


HOME  INPUT  POINTER: 

'/****;**•«**•«*****************•«******«*****«********«***•****•/ 
/*  DIRECT  INPUT  LEXICAL  ANALYZER  TO  FIRST  TOP-LEVEL  NODE  OF  •/ 
/•  INPUT  FILE.  */ 

/***•**««*«*********•••«**********•***«******««*•*******««*****•/ 


MOVE  INPUT_PARSIN6_P0INTER  TO  3EG1NNING  OF  FIRST  NODE  OF  INPUT  TREE 
IF  SUCH  A NODE  UAS'foUNO 
THEN  DO; 

SET  OPERATION  TRUE  FALSE  INDICATOR  TO  TRUE; 

SET  INPUT_SY.MBOL  TO  NULL; 

CALL  INPUT_LEXICAL_ANALYZER; 

END; 

ELSE  DOR- 
SET 0PERATI0N_TRUE_FALSE_INDICAT0R  = "FALSE” 

.!1ESSASE(I,30r 

END; 

END  .HOME  INPUT_POINTER; 


advance  input  POINTER: 

/•;•**»*;•*•*«********•***«***•****•**•***•«******«*«**«*.*•**••/ 

/*  DIRECT  INPUT  LEXICAL  ANALYZER  TO  NEXT  SAME-LEVEL  NODE  OF  */ 
/*  INPUT  FILE.  */ 

/*•****•******♦***************•*♦**#******★*****♦***♦♦***********/ 

IF  OPERATION_TRUE_FALSE_INOICATOR  ■ "FALSE"  THEN  RETURN; 


FIND  NEXT  NODE  IN  INPUT  TREE  WHICH  IS  AT  SAME  LEVEL  AS  CURRENT  NODE 
IF  SUCH  A node  was  FOUND 
THEN  DO; 

SET  OPERATION_TRUE_FALSE_r NDICATOR  TO  "TRUE"; 

MOVE  INPUT  PARSING.POINTER  TO  BEGINNING  OF  THAT  NODE; 

SET  INPUT_SYM0OL  TO  NULL; 

CALL  INPUT.LEXICAL_ANALYZER; 

END; 

ELSE  DO; 

SET  OPERATION_TRUE_FALSE_INDICATOR  TO  "FALSE"; 

SET  3R0THER_N00E._EN0  = "TRUE"; 

END; 

END  .ADVANCE_INPUT_P0INTER; 


MOVE  INPUT  POINTER  DOWN: 

/*  DIRECT  INPUT  LEXICAL  ANALYZER  TO  FIRST  NEXT-LEVEL-DOWN  NODE  */ 
/•  OF  INPUT  file.  */ 

/ •■»*■»*■•■»»****■»***  ■»*iHl*******»  *»*•»*•»*  **■»**■•**■»***  **************  / 

IF  OPERATION_TRUE_FALSE_IMOICATOR  » "FALSE"  THEN  RETURN; 

FIND  FIRST  NODE  BELOW  CURRENT  NODE  IN  INPUT  TREE; 

IF  SUCH  A NODE  WAS  FOUND 
THEN  DO; 

SET  OPERATION_TRUE_FALSE_I»OICATOR  TO  "TRUE"; 

MOVE  INPUT_?ARSING_P0INT6R  TO  3EGINMING  OF  THAT  NODE; 

SET  lNPUT_SYMBOL  TO  NULL; 

CALL  INPUT_LEXICAL_ANALrZER; 

END; 

ELSE  SET  OPER AT:0N_TRUE_FALSE  INDICATOR  TO  "FALSE"; 

END  ..MOVE_INPUT_POINTER_OOWN; 
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PARSE_INPUT  ( ARGUiEMT ) : 

/*  ATTEJ1PT  TO  RECOGNIZE  NEXT  INPUT  TOXEN  AS  INDICATED  IN  */ 

I*  ARGUMENT.  FOR  SIMPLICITY  CLASS  NAMES  AND  LITERAL  STRINGS  */ 

/*  ARE  PASSED  INDISCRIMINATELY  AS  ARGUMENTS.  THE  IMPLEMENTOR  */ 

/*  MUST  INSURE  THAT  THIS  CONFLICT  IS  AVOIDED  */ 

CONSIDER  INPUT  SYMBOL,  INPUT  SYM90L_CLASS  RETURNED  ON  PREVIOUS  INVOCATION 

OF  INPJT_LExICAL_ANALYZER; 

IF  ARGUMENT  = 'IDENTIFIER'  & I NPUT_SYM30 L_CL AS S = 'IDENTIFIER' 

! ARGUMENT  = 'NUMBER'  & INPUT_SYMBOL_CLASS  = 'NUMBER' 

! ARGUMENT  = 'STRING'  & INPUT_SYMBOlIcLASS  = 'STRING' 

• ARGUMENT  = INPUT_SYMBOL 
THEN  DO; 

SET  OPERATION_TRUE_FALSE_INDICATOR  TO  'TRUE'; 

CALL  input_lexicalIanalyzer; 

END; 

ELSE  SET  OPER ATrON^TRUE_FALSE_INOICATOR  TO  'FALSE'; 

END  .PARS£_INPUT; 


/*  FLTOPS  FUNCTION  CONTROL  OPERATIONS  * 


[*****’****«****'** 


/ 

/ 

/ 


SET  (ARGUMENT): 

/ 

/*  SET  SWITCH  OR  FLAG,  AS  INDICATED 
/ 

PERFORM  THE  ARITHMETIC  ASSIGNMENT  CONTAINED  IN  THE  ARGUMENT; 
END  .SET; 


/ 

*/ 

/ 


TEST  (ARGUMENT): 

/*  TEST  SWITCH  OR  FLAG  FOR  INDICATED  VALUE  OR  CONDITION. 

TEST  FOR  THE  TRUTH  OR  FALSEHOOD  OF  THE  BOOLEAN  EXPRESSION  CONTAINED  IN 

THF  ARGUMENT; 

IF  TRUE 

THEN  SET  FCF_PARSING_TRUE_F ALSE_INDIC ATOR  TO  "TRUE"; 

ELSE  SET  FCF~PARSIN6~TRUE~F ALSeIinDIC ATOR  TO  "FALSE"; 

END  .TEST; 
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.SCAS 


TO_LOC*TIOM  (ARGUMENT): 

/****«**♦**♦•*•********♦********************♦******★************/ 

/*  DISABLE  ALL  FLTOPS  OPERATIONS  EXCEPT  BASIC  FCF  PARSING,  */ 

/*  UNTIL  CORRESPONDING  LOCATION  (IDENTIFIABLE  BY  NUMERICAL  */ 

/*  ARGUMENT)  OF  SAME  INVOCATION  OF  SAME  RULE  IS  REACHED.  */ 

/**************************************************************<'/ 
IF  FLTOPS  FUNCTION  * SYNTAX  OR  SCAN  THEN  RETURN; 

ELSE  DO; 

SAVE  FLTOPS  FUNCTION  VALUE  AND  RESET  FUNCTION  TO  SCAN; 

SAVE  INFORMATION  INDICATING  THE  RULE  AND  LOCATION  AT  WHICH 
FLTOPS  FUNCTIONS  WILL  RESUME  IN  LOCATION_INFORMATION; 
END; 

END  .SCAN_TO_LOCATION; 


.LOCATI 

/ 

/ 

/ 

I 

I 


£ 

E 


ON  (ARGUMENT): 

***ft#**********lk*'*********i***4r*********'  **  *********#*****:*******  / 

* SEE  .SCAN_TO_LOCATION.  */ 

#*-*4»#****#*ir^*#A##*^**##i^#*****^ifr*^^*^*  it  it  it  it  ^ it  it  Itititititit^ititititititiririt/ 

F FLTOPS  FUNCTION  NOT  EQUAL  TO  SCAN  THEN  RETURN; 

F CURRENT  LOCATION  CORRESPONDS  TO  THAT  INDICATED  IN  LOCATION,! N FORMATION 
SAVED  BY  THE  LAST  INVOKED  .SC AN_TO_LOCATION  PRIMITIVE 
THEN  RESET  FLTOPS  FUNCTION  TO  SAVED  VALUE; 

LSE  RETURN; 

ND  .LOCATION; 


.ReCOVERY_POINT  (ARGUMENT): 

/*  STORE  CURRENT  FCF_PARSING_POI NTER  LOCATION.  »/ 

PUSH  FCF_PARSING_POINTER  ONTO  RECOVERY_POINT_STACK; 

END  .RECOVERY, POINT; 


.RETURN_TO,RECOVERY, POINT  (ARGUMENT) : 

/*  REINITIATE  PARSING  AT  CORRESPONDING  RECOVERY  POINT  */ 

/*  (IDENTIFIABLE  BY  NUMERICAL  ARGUMENT)  OF  SAME  INVOCATION  OF  */ 
/*  SAME  RULE.  */ 

POP  TOP  ELEMENT  FROM  RE C OVER Y ,P0 IN T_ST A C K; 

SET  FCF  ?ARSING_POINTER  LOCATION  TO  THIS  VALUE; 

SET  FCF^SYMBOL  TO  NULL; 

CALL  FCF, LEXICAL, ANALYZER; 

END  .RETURN  TO  RECOVERY_PO INT; 
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/^••«******««««*****/ 
/*  INVOICE,  EXECUTE  »/ 

/******•************/ 


.INVOICE  (ARGU.TENT): 

/ 

/*  INVOICE  INDICATED  FCf  RULE. 
/ 


/*  ARGUMENT  IS  FCF  RULE  NAME  */ 


/ 

*/ 


PUSH  RULE  NAME  (ARGUMENT)  ONTO  PROCE DURE .NAME  STAC<; 

IF  TRACE  NOT  EQUAL  "OFF” 

THEN  PRINT  RULE  ENTRY  TRACE  STATEMENT; 

IF  TRACE  NOT  EQUAL  "OFF”  AND  NO  SEVERE  ERRORS  HAVE  BEEN  ENCOUNTERED 
THEN  OUTPUT  RULE  INVOCATION  FORTRAN  COMMENT; 

IF  RULE  NAMED  IN  ARGUMENT  EXISTS  IN  FCF  PORTION  OF  INPUT  FILE 
THEN  CONSIDER  THAT  RULE; 

ELSE  IF  RULE  NAMED  IN  ARGUMENT  EXISTS  IN  FCF 
THEN  CONSIDER  THAT  RULE; 

IF  RULE  RAS  FOUND 
THEN  DO; 

SET  FCF_PARSING_POINTER  TO  FIRST  ELEMENT  AFTER  RULE  LABEL; 

SET  FCF"sYMBOL  TO  NULL; 

CALL  FCF  LEXICAL.ANALYZER; 

SET  OPERATION.TRUE.F ALSE.INDICATOR  TO  "TRUE"; 

E N D ; 

ELSE  SET  OPERATION_TRUE_FALSE_INOICATOR  TO  "FALSE"; 

END  .INVOCE; 


.ENO.PROCEOURE  (ARGUMENT): 

/*  RETURN  FROM  INVOICED  FCF  RULE.  */ 

VERIFY  THAT  ARGUMENT  MATCHES  TOP  ELEMENT  OF  PR OC E D UR E _NAMt  STACC; 
IF  TRACE  NOT  EQUAL  "OFF" 

THEN  PRINT  RULE  EXIT  TRACE  STATEMENT; 

POP  TOP  ELEMENT  FROM  PROC E OUR E .N AME.ST A C X; 

END  .END. PROCEDURE; 


.EXECUTE  (ARGUMENT): 

/ A************************************  **  **«•*•«**•***«  ««*•«**.  . > / 

/♦  EXECUTE  INDICATED  FORTRAN  SUBROUTINE  AT  PRECOMPILER  TIWE.  •/ 

/**•**•*•****«***«**•*«*******************•****«********«**«•«**/ 

TRANSFER  CONTROL  TO  THE  ROUTINE  NAMED  AS  THE  ARGUMENT; 

DATA  COMMUNICATIONS  ARE  MAINTAINED  THROUGH  THE  £ X E CU TE .D AT A .AR E A ; 
END  .EXECUTE; 
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EXECUTe_DATA_AR£A_UPOATE: 

/****w*******W****‘*#*##************##*ir********/ 

/*  DATA  IS  'lOVEO  FROM  SYMBOL  TABLE  LOCATIONS  */ 

/*  TO  THE  EXECUTE_OATA_AREA  OR  VICE  VERSA.  */ 

/<-  FORMAT  OF  OATa'iS  MAINTAINED  IN  A FORM  *t 

/*  ACCEPTABLE  FOR  THE  EXECUTING  PROGRAM  IN  THE*/ 

/*  £XECUTE_OATA_AREA  AND  IN  STRING  FORMAT  IN  */ 

/*  THE  SYMBOL  TABLES  */ 

/*ift'*'*-*'*#**##Ar***#**lk**ArA'*1^ifr#**'***Ar*ifr##Ar*  **  -k-tt  it  ir  it  f 

IF  CONVERT_FLAG  SET  TO  "IN” 

THEN  DO; 

SET  ORIGIN  TO  PARAMETER  LOCATION; 

SET  DESTINATION  TO  EX ECUTE_0 AT A_AR EA_POI NT ER ; 
END; 

ELSE  DO; 

SET  ORIGIN  TO  EXECUTE.OATA_AREA_POINTER; 

SET  DESTINATION  TO  PARAMETER  LOCATION; 

END; 

DO  FOR  EACH  OF  THE  “ARAMETER.SIZE  VALUES; 

MOVE  VALUE  FROM  ORIGIN  TO  DESTINATION; 

CONVERT  VALUE  ACCORDING  THE  THE  SPECIFICATION  FOUND 
»ARAMETER_CLASS  AND  CONVERT_FL AG ; 

/*  CONVERT  FLAG  = IN  CHANGE  VALUE  TO  FORM  USEABLE  BY 

/*  CONVERT^FLAG  = OUT  CHANGE  VALUE  TO  FORM  OF  LITERAL 
/*  “ INSERTION  INTO  SYMBOL  TABLES 

INCREMENT  ORIGIN  AND  DESTINATION; 

END; 

END  .EXECUTE.DATA  AREA  UPDATE; 


IN 

EXECUTING  PROGRAM  * 
STRING  FOR  * 

* 


EXECUTE_PARAMETER_UPDATE: 

fkkkiiititkitkitiiititititititititkitititititiKitkitititiiititiiitititititf 

/*  UPDATES  SYMBOL  TABLE  LOCATIONS  AFTER  */ 

/*  COMPLETION  OF  AN  EXECUTE  ROUTINE  */ 

/****************************************/ 

SET  EXECUTE_OATA_AREA_POINTER  TO  FIRST  VALUE  TO  BE  TRANSFERRED; 

DO  FOR  EACh'paRAMETEr'iN  TABLE  EXECUTE_R OUTINE_N AME; 

GET  VALUE  FOR  PARAMETER  CLASS^  P A RA ME TER_S I ZE  AND  PARAMETER.LOCATION  ; 

.EXECUTE_OATA  AREA_UPOATE 

UPDATE  EXECUTE_DATA,AREA_POINTER; 

END; 

END  .EXECUTE  PARAMETER  UPDATE; 
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/*  BOOLEAN  OPERATIONS  */ 

/******«***************/ 


AND: 

/******«********************************************************/ 

I*  rA<E  LOGICAL  AND  OF  TWO  BOOLEAN  ELEMENTS  */ 

/**«****************************************♦*************»*****/ 

REMOVE  TOP  T(iO  ELEMENTS  OF  THE  900LEAN_TRUTH_STACIC; 

TA<E  LOGICAL  AND  OF  THESE  TWO  ELEMENTS  ; 

PUSH  RESULTING  VALUE  ONTO  THE  TOP  OF  THE  BOOLE AN_TRUTH_STACK  ; 

END  .AND; 


OR: 

/*«************************«*****************************«******/ 

/*  COMPUTE  LOGICAL  OR  OF  TWO  BOOLEAN  ELEMENTS  */ 

/^At^************************************  *******************«****/ 

REMOVE  TOP  TWO  ELEMENTS  OF  THE  BOOL E A N _T RUTH _S TA C K ; 

TAKE  THE  LOGICAL  OR  THE  THESE  T<JO  ELEMENTS  ; 

PUSH  THE  RESULTING  VALUE  ONTO  THE  TOP  OF  THE  BOOLEAN_TRUTH_STAC<  ; 
END  .OR; 


NOT: 

/******«********************************«************ 

I*  COMPUTE  THE  COMPLEMENT  OF  A BOOLEAN  ELEMENT 
Z**************************************************** 
REMOVE  TOP  ELEMENT  OF  THE  BOOLE AN_TRUTH_STACK  ; 

TAKE  LOGICAL  COMPLEMENT  OF  THIS  ELEMENT  ; 

PUSH  RESULTING  ELEMENT  ONTO  THE  TOP  OF  THE  BOOLEAN.TR 
END  .NOT; 


SAVE_TRUTH: 

/*************************★*******'************'******** 

/*  SAVE  CURRENT  VALUE  OF  OPERATION  TRU£_FALSE_INOICATO 
/*  ON  THE  300LEAN_TRUTH_STACK. 
/*«**********'*************************«’*************** 

PUSH  VALUE  OF  OPERATION  TRUE, FALSE  INDICATOR  ONTO  THE 
THE  300LEAN_TRUTH, STACK  ; 

END  .SAVE_TRUTH; 


300LEAN_C0MPARE  : 

/**«•*******•***************#*•***********************«******•**/ 

/*  EVALUATES  RELATIONAL  EXPRESSIONS  TO  DETERMINE  TRUE/FALSE  */ 


/***************************•**************«•**********«*****«*•/ 

CONSIDER  THE  TYPE  OF  RELATION  SAVED  IN  THE  RELATION  TYPE  FLAG  ; 

COMPARE  VALUE  IN  SAVED  VALUE  JITHI  THE  VALUE  IN  COMPUTED  VALUE; 

IF  THE  RELATION  IS  TRUE  THEN  SET  OPER A TION_TRUE_F ALSE.I NDI C A TOR  TO  TRUE 
ELSE  SET  OPERATION  TRUE.F ALSE ,I NO IC A TOR  TO  FALSE  ;* 

ENO  .300LEAN_C0MPARE; 


*******  **/ 
’f 

******  * . • . / 


TH_STACK  ; 


**********/ 

R */ 

*/ 

**********/ 

TOP  OF 
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/********«*********/ 
/*  FORTRAN  OUTPUT  */ 
/******************/ 


.OUTPUT  (ARGUMENT); 

/********************«*«***«***********#**********«*************/ 

/*  OUTPUT  FORTRAN  STATEMENT  WHICH  HAS  BEEN  READ  FROM  FCF  (OR  */ 
/*  FROM  FCF  PORTION  OF  INPUT  FILE),  SUBSTITUTING  REPLACEMENT  */ 
/*  STRINGS  AS  INDICATED  BY  APPROPRIATE  TABLE.  •/ 

/*********************************************************«*****/ 
IF  FLTOPS  FUNCTION  NOT  EQUAL  TO  FULL  THEN  RETURN; 


PLACE  FORTRAN  PARSING_POINTER  ON  FIRST  CHARACTER  OF  ARGUMENT; 

CALL  FORTRAN_LEXICAL_ANALYZER; 

.SAVE  POINTER; 

IF  PASS1  PASS2  SWITCH  = 1 

THEN  OUTPUT'fiLE  * PASS1  OUTPUT.FILE; 

ELSE  OUTPUT  FILE  * PASS2  OUTPUT.FILE; 

DO  WHILE  (FORTRAN  SYMBOL  IS  NOT  "END  OF  FILE"); 

/«  END  OF  FILE  IN  THIS  CONTEXT  REFERS  TO  LOGICAL  END  OF  ARGUMENT  STRING  «/ 
IF  FORTRAN_SYMBOL  = STATEMENT.TERMINA TOR 
THEN  DO; 

WRITE  0UTPUT_3UFFER  TO  OUTPUT_FILE  ; 

IF  FLTOPS  OUTPUT  = FORTRAN 
THEN  DO; 

MA<E  SURE  CORRECT  FORTRAN  CARD  IMAGE  SYNTAX  IS  OROVIOED; 
PROVIDE  CONTINUATION  STATEMENTS  AND  SEQUENCE  NUMBERS 
IF  NECESSARY; 

END; 

CLEAR  OUTPUT  BUFFER; 

END; 

IF  PASS1_PASS2_SWITCH  * 1 
THEN  .FIND  TABLE (PASS1 ) ; 

ELSE  .FIN0ItA8LE(PASS2); 

.TEST_F0R_SYM80L(F0RTRAN_SYMB0L); 

IF  OPERATION  TRUE  FALSE  INDICATOR  = "TRUE" 

THEN  WRITE  VALUE  ASSOCIATED  WITH  CURRENT  SYM80L_TABLE_PCI NTER 

TO  OUTPUT.BUFFER; 

ELSE  WRITE  FORTRAN  SYMBOL  TO  OUT PU T_3U F F ER ; 

CALL  FORTRAN_LEXICAL_ANALYZcR; 

END; 

.RESTORE  POINTER; 

IF  trace"*  "HIGH"  OR  "HIGHER" 

THEN  WRITE  FORTRAN  OUTPUT  TRACE  MESSAGE; 

IF  STRING  SUBSTITUTION  WAS  PERFORMED  ABOVE 

THEN  ADO  ENTIRE  OUTPUT  FORTRAN  STATEMENT  TO  LIST 
OF  ALTERED  OR  GENERATED  STATEMENTS; 

END  .OUTPUT; 
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.AOJJST.COLUMH  (CDLUMN.NUMSER ) : 

/**•*•**«*•*••**•*«***•*****•»»*•*•***•*••••••*•*•*••*•••«••*.•*/ 

/*  INSURE  THAT  NEXT  ELEMENT  OUTPUT  BEGINS  IN  COL  CDLUNN_NUMBtR  •/ 

/ ***•*****•****••****•***•****•**•****•*•**••**•*•**••*;•«••*•••/ 

IF  LENGTH  OF  0UTPUT_3UFFER  > COLUMN  NUMBER  THEN  DO; 

OUPUT  CURRENT  CONTENTS  OF  0JTPUT~3U F F ER ; 

SET  OUTPUT  BUFFER  TO  NULL; 

WRITE  WARNING  MESSAGE  INDICATING  THE  ACTION  JUST  TAKEN; 

ENDL"; 

PAO  OUTPUT  BUFFER  WITH  SUFFICIENT  BLANKS  SO  THAT  ITS  LENGTJH*"H  EQUALS 
COLUMN_NU1BER  - 1; 

END  .AOJUST.COLUMN; 


.FORMAT  STRING  (STRING  IN, FORMAT): 

/***************;************* •************••***•* ****««*****^ 

/*  REFORMAT  CONTENTS  OF  STRING,  ACCORDING  TO  SPECIFICATION  IN 
/*  FORMAT.  RETURN  REFORMATED  STRING  IN  TEMPORARY  STRING 


»*/ 

*/ 

*/ 


IF  FIRST  CHARACTER  OF  FORMAT  IS  NOT  LEGAL  FORMAT  TYPE  (I.E.  AT  LEAST 
A,E,F  OR  I)  THEN  DO; 

WRITE  OUT  SEVERE  ERROR  MESSAGE  INDICATING  ILLEGAL  FORMAT  TYPE; 

RETURN; 

END; 

IF  THE  CONTENTS  OF  STRING  IN  ARE  NOT  COMPATABLE  WITH  THE  INDICATED 
FORMAT  TYPE  THEN  DO; 

WRITE  OUT  SEVERE  ERROR  INDICATING  THE  FORMAT/DATA  DISCREPENCY; 
RETURN; 

END; 

If  THE  FORMAT  CONSISTS  OF  SIMPLY  THE  FORMAT  TYPE  DESIGNATOR  ( I.E. 

SIMPLY  AN  I OR  F ETC.  ) THEN  REFORMAT  STRING_IN  USING  THE  DEFAULT 
PROCEDURE  (IMPLEMENTATION  OPTION)  CORRESPONdFnG  TO  THE  FORMAT  TYPE, 
( E.G.  FOR  AN  I FORMAT,  THEN  VALUE  COULD  BE  ROUNDED,  SCALED 
THEN  OUTPUT  ) 

ELSE  IF  FORMAT  IS  A LEGAL  FORMAT  (E.G.  F10.4  NOT  FZ.T)  THEN  REFORMAT 
STRING, IN  ACCORDINGLY  AND  PLACE  RESULT  IN  TEMPORARY_STRIN6; 

ELSE  WRITE  OUT  SEVERE  ERROR  MESSAGE  INDICATING  THE  BAD  FORMAT; 

END  .FORMAT_STRING; 

/**4**************«*'*********«*'*/ 

/*  ERROR  AND  STATUS  OPERATIONS  »! 

/.*****•******••***•***********«/ 

.ERROR  (MESSAGE,  SPE C I AL,I NSTRUC T IONS > : 

/*  WRITE  ERROR  MESSAGE  IF  AND  ONLY  IF  IMMEDIATELY  PRECEDING  */ 

/*  SYNTACTIC  ELEMENT  WAS  NOT  SATISFIED.  */ 

IF  FCF,PARSING_TRUE_FALSE_INDICAT0R  =>  "FALSE" 

THEN  .MESS AGE (TYPE, MESSAGE, SPECIAL, IN  ST RUCTIONS) 

END  .ERROR; 
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/•••••••«•«<••••  eRROII  McSSASE  table 

/*•  ««••«•••«««•««••••«*•••««•«<«•«••«•««««*••*•••••••«*••««••<•••*••/ 

/••  NU'TSER  ••  •*•••  error  RESSACt  •••••  •/ 

/•* 

/••  1 TS:UNREC06n1ZE0  STATERENT  '/ 

2 tS:OESlREO  INPUT  NOT  FOUND  •/ 

/••  1 fSsNISSlNC  END  FOR  NAIN  PROCEDURE  •/ 

/••  A FUiOESlRED  SrnaOL  does  not  exist  in  table  nape  specified  •/ 

/••  S r'.:NISSING  left  parenthesis  *-  ASSUNEC  PRESENT  •/ 

/•*  6 FU:NISSIN«  RUNT  PARENTHESIS  — ASSURED  PRESENT  •/ 

/••  7 FUsRlSSINS  COHNA  --  ASSURED  PRESENT  •/ 

/•*  B Fw:NON-ENPTT  STNBOL  TABLE  •/ 

/••  9 CSlASSERTION  failed  •/ 

TO  FStNISSINC  OR  ILLEGAL  PARAPETER  TYPE  IDENTIFIER  */ 

11  FSlNISSING  OR  ILLEGAL  RELATIONAL  OPERATOR  IN  BOOLEAN  EXPRESSION  •/ 

/••  12  FU:NISSING  OR  ILLEGAL  RULE  NAME  ON  F CF  PROCEDURE  •/ 

13  FStMISSING  OR  ILLEGAL  WORD  IN  A ’DO  FOR’  BLOCK  CONSTRUCT  •/ 

/*•  1A  FSiFlISSING  OR  illegal  ELEMENT  IN  VALUE  STATEMENT  •/ 

/”  IS  FS:UNRECOGNIIEO  OR  INVALID  INPUT  REOUEST  •/ 

/*•  ID  FSlNISSING  OR  ILLEGAL  ELEMENT  IN  AN  ARITHMETIC  EXPRESSION  •/ 

/••  17  FW:MISSING  ’:’  ON  COMMENT  OR  ERROR  SPECIFICATION,  AS!L'MED  PRESENT’/ 

/”  IB  FS:EXTRA  STATEMENTS  BEYOND  THE  EXPECTED  END  OF  FCF  PROCEDURE  •/ 

/••  19  FSiMISSING  OR  ILLEGAL  FORMAT  ELEMENT  IN  FORMAT  STATEMENT  •/ 

/”  2C  FS:MISSING  END  STATEMENT  ON  ’DC  WHILE”  BLOCK  ’/ 

/••  21  FStMISSING  END  statement  ON  ’DC’  BLOCK  •/ 

/”  22  FStMISSING  END  STATEMENT  ON  ’DC  FCR  SYMEOL  TABLE’  BLOCK  •/ 

/••  23  FwtMISSING  WORD  "SU8N00E’  — ASSUMED  PRESENT  */ 

/”  2A  FStMISSING  END  STATEMENT  ON  ’DO  FCR  EACH  SUBNCDE  OF’  BLOCK  •/ 

/”  25  FStMISSING  COMMA  — MUST  BE  PRESENT  •/ 

/••  26  FStONLT  STRING  LITERALS  ALLOWED  IN  MESSAGE  STATEMENTS  ’/ 

/”  27  FStMISSING  ARRAY  DEFINITION  OR  “AS"  CLAUSE  IN  DEFINE  STATEMENT  •/ 

/”  28  FStMISSING  RIGHT  PARENTHESIS  — MUST  BE  PRESENT  •/ 

/••  29  FStUNRECOGNIIEO  ELEMENT  IN  BOOLEAN  EXPRESSION  --  •/ 

/”  30  IWtlNPUT  FILE  EMPTY  •/ 

/”  31  IWtDESIREO  input  TREE  NOT  FOUNC  •/ 

/”  32  FStMISSING  OR  ILLEGAL  BOOLEAN  EXPRESSION  •/ 

/”  53  FSiEXPECTED  ’THEN"  CLAUSE  IN  "IF’  STATEMENT  NOT  FOUND  •/ 

/••  3a  FutMISSING  WORD  ’TABLE’  — ASSUMED  PRESENT  •/ 

/”  33  FStMISSING  OR  illegal  SYMBOL  TABLE  NAME  •/ 

/••  36  FWtMISSING  WORD  'Of’  — ASSUMED  PRESENT  •/ 

/”  37  TWt’DO  FOR  EACH  SUBHODE’  BLOCK  BTPASSEO--NC  SUBHODES  FOUND  •/ 

/••  3S  FStMISSING  OR  illegal  RULE  NAME  IN  "INVOKE’  STATEMENT  •/ 

/••  19  FStMISSING  END  STATEMENT  ON  FCF  RULE  •/ 

/”  AO  FStMISSING  OR  ILLEGAL  SY’BOL  NAME  •/ 

/”  A1  FStMISSING  OR  ILLEGAL  VALUE  FIELD  IN  MESSAGE  STATEMENT  •/ 

/”  42  FStVALUE  FIELD  REGUIRED  IN  “REPLACE”  STATEMENT  •/ 

/”  43  FutMISSING  OR  ILLEGAL  MESSAGE  TYPE  — TYPE  GENERAL  ASSLMED  •/ 

/••  44  FStMISSING  OR  ILLEGAL  ROUTINE  NAME  FOR  "PARAMETERS"  DR  "EXECUTE"  •/ 

/*•  AS  FStMISSING  OR  illegal  FORM  FOR  PARAMETER  IN  "EXECUTE"  STATEMENT  •/ 

/••  46  FStMISSING  OR  ILLEGAL  ELEMENT  WIThIH  AN  "OUTPUT"  STaIEMENT  •/ 

/”  A7  FStMISSING  OR  ILLEGAL  ARITHMETIC  EXPRESSION  •/ 

/”  48  FStMISSING  OR  illegal  ELEMENT  IN  » SUBSCRIPT  SPECIFICATION  •/ 

/”  49  FSiEXTRANNEOUS  "ELSE"  CLAUSE  '/ 

/”  SO  FStEXTRANNEOUS  "THEN"  CLAUSE  •/ 

/A.  51  FSt"PARANeTERS"  statement  MUST  PRECEDE  COR »E SPONO I NG  "EXECUTE"  •/ 

/”  S2  FUtTHE  RULE  REOUESTED  WAS  NOT  FOUND  •/ 

/”  S3  IWtUNUSED  INPUT  •/ 

/••  S4  FStMISSING  OR  ILLEGAL  FORM  FOR  INPUT  THEE  SEARCH  SIA’EMENT  •/ 

/”  SS  FStHEAOING  OUTPUT  IN  "STATUS"  STAIf’ENT  MUST  BE  A STRING  LITERAL  •/ 

/••  56  NlINDICAT'O  SYMBOL  NOT  PRESENT  UncN  DELETE  ATTEMPTED  --  •/ 

/••  57  IStSPECIFIEO  input  TREE  DOES  NOT  EXIST  •/ 

/”  SB  FSiILLEGAL  FOR".  FOR  STRING  IDF'lTlFIE*  IN  "SUBSTRING"  STATE’ENT  •/ 
/•• 


! 


i 


r 
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1 


.'MESSAGE  ('1ESSAGE,  SP  E C I A L_1  M S TRU  C T I DNS ) : 


/•  WRITE  ERROR  MESSAGE  CONTAINED  IN  "MESSAGE”  ARGUMENT,  USING  */ 
/*  SEVERITY  LEVEL  INDICATED  9Y  FIRST  CHARACTER  OF  MESSAGE,  IN  */ 


/*  FORMAT  INDICATED  3Y  "TYPE"  ARGUMENT.  IF  OPTIONAL  */ 
I*  "SPECIAL.INSTRUCTIONS"  ARGUMENT  IS  PRESENT,  PERFORM  THE  */ 
/*  OPERATIONS  INDICATED  (IN  PDL)  THERE.  */ 

/*******«********•******************•*************•**********«•*/ 


NOTE  THAT  IF  MESSAGE  IS  A NUMBER  THEN  IT  WOULD  3E  RETRIEVED  FROM 
THE  ERR0R_MESSAGE_TA8LE;  ALL  CATENATIONS  HAVE  ALREADY  BEEN  DONE; 

NOTE  THAT  FIRST  CHARACTER  OF  MESSAGE  IS  TYPE,  SECOND  IS  SEVERITY  CODE, 
THIRD  IS  COLON,  REMAINDER  IS  MESSAGE  TEXT; 

IF  TYPE  = I /*  I INDICATES  INPUT  PARSING  ERROR  */ 

THEN  STORE  I NPUT_P A RS I NG_PD I NTE R LOCATION,  MESSAGE  FOR  LATER  OUTPUT; 
ELSE  IF  TYPE  = F ” “ /*  F INDICATES  FCF  PARSING  ERROR  */ 

THEN  STORE  FCF  RULE  NAME  (TDP  ELEMENT  OF  PROCEDURE  NAME_STACX), 
POSITION  IN  RULE,  MESSAGE  FOR  LATER  OUTPUT; 

ELSE  IF  TYPE  = G /*  G INDICATES  GENERAL  ERROR  CLASS  */ 

THE^  OUTPUT  MESSAGE  IMMEDIATELY  UNLESS  SEVERITY  = "N”  AND  NOTES  = "NO 
WHENEVER  OUTPUT,  MESSAGE  WILL  HAVE  FORMAT  BELOW,  WHERE  S IS  SEVERITY: 


S ***  TEXT  OF  ERROR  MESSAGE 

IF  SEVERITY  = "F"  /*  FATAL  ERROR  *! 

THEN  DO;  /*  NOTE  THAT  MESSAGE  HAS  ALREADY  SEEN  OUTPUT  OR  STORED  */ 

IF  THIS  IS  SECOND  FATAL  ERROR 
THEN  STOP; 

.OUTPUT  STATUSC’FLTOPS  STATUS  AT  TIME  OF  FATAL  ERROR:"); 
.OUTPUT”eRRORS; 

TAKE  ACTION  TO  STOP  ALL  SUBSEQUENT  JOB  STEPS; 

END; 

ELSE  IF  SEVERITY  = ”S”  AND  TY^E  = "F"  /*  SEVERE  ERROR  IN  FCF  */ 

THEN  DO; 

IF  StVERE_ERROR. COUNT  = D THEN 

.OUT?uf_STATUS("FLTOPS  STATUS  AT  TIME  OF  FIRST  SEVERE  ERROR:"); 
INCREMENT  SE V E R E _E RR 0 R_C DUN T ; 

SET  FLTOPS  FUNCTION  TO'SYNTAX;  t*  CHECK  ONLY  FCF  SYNTAX  */ 

DO  WHILE  FCF_SYM30L  IS  NOT  A KEYWORD; 

/*  KEY  WORD  TABLE  CONTAINS  KEY  WORDS  */ 

CALL  FCF_LEXICAL_ANALYZER; 

END; 

SET  FCF  PARSING  TR UE . F A L SE _I N 0 I C A T OR  TO  "TRUE”; 

TRANSFER  PARSKG  CONTROL  TO  THE  '’OINT  FROM  WHICH 
THE  "S r ATEMENT"  RJLE  WAS  MOST  RECENTLY  INVOKED; 

END; 

ELSE  IF  SEVERITY  = "S"  AND  TYPE  = "I"  /*  SEVERE  ERROR  IN  INPUT  */ 

THEN  DO; 

IF  SEVERE  ERROR  COUNT  = 0 THEN 

.OUfPUT_sfATUS( ’ FLTOPS  STATUS  ON  FIRST  INPUT  SFVERE  ERROR')' 
INCREMENT  SEVERE.ERROR.COUNT; 

IF  FLTOPS  FUNCTION  = FULL  THEN  SET  FUNCTION  TO  TEST; 

/'  INHIBIT  FURTHER  FORTRAN  OUTPUT  */ 

END; 

ELSE  IF  SEVERITY  = "W"  /•  WARNING  */ 

THEN  INCREMENT  W ARN I NG_C OUN T ; 

ELSE  IF  SEVERITY  = "N"  ~ /*  NOIF  *! 

THEN  INCREMENT  N0TE_C0UNT; 

NOTE:  IF  THIS  ERROR  MESSAGE  HAS  BEEN  CUToUT  FOR  THE  SPECIFIC  LOCATION 
ONCE  BEFORE  THEN  DON'T  OUTPUT  AN  ERROR  MESSAGE  THIS  TIRE. 

END  .MESSAGE; 
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/******************************/ 


KEY  WORD  TABLE  ENTRIES 

**/ 

/ «** 

***/ 

IF 

/** 

DO 

**/ 

/** 

INVOKE 

/** 

INPUT 

**/ 

/** 

SYMBOL_EXISTS 

**  / 

/** 

TABLE  EMPTY 

**/ 

/** 

NOOE_EXISTS 

**/ 

/** 

ASSERT 

/** 

STATUS 

/** 

FIND 

**/ 

/** 

EXECUTE 

/** 

PARAMETERS 

**/ 

MESSAGE 

**/ 

/** 

SET 

/** 

INCREMENT 

**/ 

/** 

DECREMENT 

**/ 

/** 

OUTPUT 

**/ 

/** 

ENTER 

**/ 

/** 

CATENATE 

**/ 

/*• 

REPLACE 

**! 

/** 

DELETE 

**! 

/** 

CLEAR_TABLE 

/** 

DEFINE 

**/ 

/** 

SAVE  POINTER 

**/ 

/** 

RESTORE  POINTER 

**/ 

/** 

ELSE 

/** 

THEN 

/** 

END 

**/ 

/** 

END  OF  FILE 

**/ 

/*************«****************/ 

.OUTPUT_STATUS  (HEADING): 

/ ***  **********************************************************  * * / 
/*  OUTPUT  "HEADING"  ARGUMENT,  FOLLOWED  BY  DETAILED  INFORMATION  */ 
/*  CONCERNING  CURRENT  CONTENTS  OF  SYMBOL  TABLES  AND  ANY  OTHER  */ 
/*  RELEVANT  STATUS  INFORMATION.  */ 

/■***********************♦*♦*******♦***♦♦*♦♦********♦*******•**■***/ 
WRITE  HEADING; 

WRITE  NAME,  CONTENTS  OF  EACH  SYMBOL  TABLE; 

IF  STATS  = "YES" 

THEN  WRITE  TABLE  OF  FCF  RULE  INVOCATION  FREQUENCIES; 

IF  THERE  WAS  A FATAL  ERROR  OR  SEVERE_ERROR_COUNT  = 1 
THEN  DO; 

WRITE  ABBREVIATED  REFERENCE  TO  CURRENT  I N'»UT_PAR  SING_POI  NTER 
LOCATION; 

WRITE  CURRENTLY  INVOKED  FCF  RULE  WITH  POINTER  TO  CURRENT 
FCF  PARSING  POINTER  LOCATION; 

IF  TRACE  » "HIGHER" 

THEN  OUTPUT  FLTOPS  INTERNAL  SWITCHES,  VALUES; 

TAKE  NECESSARY  STEPS  TO  INHIBIT  SUBSEQUENT  JOB  STEPS  THAT 
RELY  ON  SUCCESSFUL  COMPLETION  OF  PRECOMPILER; 

END; 

ELSE  LIST  ALL  SYNTHESIZED  FORTRAN  STATEMENTS; 

END  .OUTPUT.STATUS; 
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OUTPUT  ERRORS: 

/IT** **#**«•*************«***•***•********••••***•***** •*«•**«***/ 

/*  WRITE  ERROR  MESSAGES  FOR  IRi»UT,  FCF  FILES.  THESE  MESSAGES  */ 
/-*  WERE  PREVIOUSLY  SAVED  FOR  OUTPUT  NOW.  IN  WRITING  INPUT  */ 

/*  ERROR  MESSAGES^  GENERATE  MESSAGES  FOR  UNUSED  INPUT  */ 

/*  INFORMATION.  WRITE  ERROR  MESSAGE  FREQUENCY  TABLES.  */ 

/ ****************************** ***yMr»*** ************** **********/ 

DO  FOR  EACH  NODE  IN  INPUT  PORTION'  OF  INPUT  FILE; 


WRITE  TEXT  OF  NODE  (IN  30C'd  PRINT  If  THERE  IS  ERROR  MESSAGE); 

IF  INPUT  ERROR  MESSAGE  WAS  STORED  FOR  THIS  NODE 

THEN  WRITE  POSITION  POINTER,  MESSAGE  IN  APPROPRIATE  PLACE; 

IF  ENTIRE  NODE  WAS  NOT  PARSED  DURING  FLTOPS  PROCESSING 
T>EN  00; 

^ WRITE  POSITION  POINTER  TO  SHOW  PARSING  PROGRESS; 

.MESSAGE(I,53) 

INCREMENT  WARNING  COUNT; 

END; 

WRITE  ERROR  FREQUENCY  TABLE  FDR  INPUT,  INCLUDING  S E VER E,ERROR_CDUNT , 
WARNING  COUNT,  NOTE_COUNT; 

DO  FOR  EACH  FCF  RULE  FOR  WHICH  FCF  ERROR  .MESSAGE(S)  WAS  (WERE)  STORED 
WHITE  RULE; 

WRITE  POSITION  POINTER,  ERRDR  MESSAGE  IN  APPROPRIATE  PLACE; 

END; 

WRITE  ERROR  FREOUENCY  TABLE  FOR  FCF; 

WRITE  OVERALL  ERROR  FREQUENCY  TABLE  ; 

END  .OUTPUT_£RRORS; 

/*************************/ 

/*  ARITHMETIC  OPERATIONS  */ 

/*************************/ 


COMPUTE_VALUE  : 

/***************************************************/ 

/*  PERFORMS  ARITHMETIC  COMPUTATIONS  (♦,-,*,/,**)  */ 

/•  IMPLEMENTATION  SHOULD  PROVIDE  MEANS  TO  CONVERT  */ 
/•  STRINGS  TO  NUMERIC  FORM  AND  VICE  VERSA  */ 

/*  COMPUTED_VALUE  CONTAINS  NUMERIC  FORM  */ 

/*  TEMPORARY  STRING  CONTAINS  STRING  FORM  */ 

/«**•**«** *«!*** ************* ***************** ******/ 
POP  TOP  element  from  OPFHA  ft'H_STACA; 


POP  TOP  ELEMENT  FROM  AR 1 TH ME T I C _S T A C K AND  SAVt  AS  V; 

POP  NEXT  ELEMENT  FROM  AR I T H ME T I C _S T A C K AND  SAVE  AS  X; 

PERFORM  THE  DESIRED  OPERATION; 

/•**  THE  OPERATIONS  SHOULD  BE  PERFORMED  AS  FOLLOWS  **•/ 
/***  X*Y  X-Y  X*Y  X/Y  X**Y  ***/ 

SAVE  THE  RESULT  IN  COMPUTEO_VALUE  AND  ALSO  PUSH  RESULT  ONTO 
ARITHMETIC_STACX; 

END  .COMPUTE_VALUE; 
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/*•********#*****************/ 
/*  MISCELLANEOUS  OPERATIONS  *! 
/****************************/ 


.30  (ARGUMENT): 

/****«************•********«*••***•*******************«*****«»•*/ 

/*  CATCH-ALL  ELEMENT  WHICH  ALLOWS  DIRECT  PDL  DESCRIPTION  IN  */ 
/*  GRAMMAR.  */ 

/•****«******#**************************«•**********«**********•/ 
PERFORM  THE  FUNCTION(S)  DESCRIBED  IN  PDL  IN  THE  ARGUMENT; 

END  .DO; 

.FALSE: 

/**************««***********************************************/ 

/•  FORCE  FAILURE  OF  RULE,  ALTERNATIVE,  ETC.  NOTE  THAT  THIS  */ 

/*  ELEMENT  IS  CONSIDERED  SEMANTIC,  EVEN  THOUGH  IT  ALTERS  THE  */ 
/*  VALUE  OF  FCF  PARSING^TRUE  F ALSE _I ND I C ATOR . */ 

/•*«***«** *****;*******;****r************************* **********/ 

SET  FCF  PARSING  TRUE  FALSE  INDICATOR  TO  »FALS£'; 

END  .FALSE; 

.TRUE  : 

/*******«**********«*******4r**«********#*********************#**/ 

/*  FORCE  COMMITMENT  TO  RULE  OR  ALTERNATIVE.  INDICATE  SUCCESS.  */ 
/«************•*«****************************************♦******/ 

SET  FCF_PARSING_TRUE_FALSE_INOICATOR  TO  'TRUE'; 

END  .TRUE; 
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fltops  functional  definition  grammar 


/******•************/ 

/*  BASIC  STRUCTURE  */ 


GOAL.RULE  := 

FLTOPS  ; 


FLTOPS  := 

.PREPR0CESS_INPUT_FILE 
.SET(PASS1_PASS2_SWITCH  = 1) 

,SET(OEFAULT_SYMaOL_TABLE  = "FLTOPS") 

.S£T(ARITH,ELEMENT_FOUNO  = "FALSE") 

• SEKARITh'vaLUE.STORED  = "FALSE") 

.SEKARITH^OEPTH^COUNTER  = G) 

.set(arith“paren"=  0) 

.SET(RELATToNAL_EXPRESSION  = "FALSE") 

.FIN0_TA8LE(FLT0PS) 

. FINOIOR_ENTER  S YMQOL ( 0 E8UG ) .ENTER_VALUE (OFF ) 

.F IN0_O»2eNTErIsyM9OL( FUNCTION)  . F N TER _V ALU E ( F ULL ) 

. FIND^ORIeNTER.SYMSOLCSTATS)  .ENTER_VALUE (OFF ) 

.F INDOOR "enter 'symbol (TRACE)  . ENTER "vALUE (OFF) 
.FINO^Or'eNTErIsyMBOLCNOTES)  . enter IvALUE (OFF) 

. FINO~Or"eNTER_S YM50L (LBLNUM)  .ENTEpIvALUE (99G00 ) 

. FINO^OR'eNTEr's YMBOL( LENGTH)  .ENTER ~V ALU E (C  FF> 

.findIor"enterIsymbol(real)  .enterIvaluec ') 

.F IN O_OrIeNTER_SYM0OL( INTEGER)  .ENTER "vALUE ( • ') 

.find”or3enter_symbol(logical)  .enter"value ( • •) 

, FINo2orIenTER_SYMBOL(  ALPHA)  . ENTER  ^VALUEC') 
.fino'or~enterIsymbol(xref ) .ENTER^VALUE (OFF) 

. F IN O^ORIeNTER "symbol (OUTPUT)  . £N T E R ALU E ( F OR TR AN ) 

.INVOicE(MAIN) 

% STATEMENT 

( "END"  "MAIN"  .ERR0R(12) 

! .TRUE  .MESSAGE(3)  ) 

( .PEEK("END_OF_FU  E") 

? -TRUE  .MESSAGE<1R) 

S(  STATEMENT  • "ENO*  ) 

.S£T(PASS1_PASS2_SW1TCH  ' 2) 

( .TESKSEVERE  ERR0R_C0UNT  = C) 

.00(PLACE  FCF_PARSING_POINTER  ON  FIRST  CHARACTER  OF  FASS1  OUTPUT  FILE; 
CALL  FCF_LEXICAL_ANALYZER;) 

${  .FORTRAN  ".OUTPUT?*)  .OUTPUT (STATEMENT  TERMINATOR)  ) 

"END  OF  FILE" 

! .TRUE  ) 

.OUTPUT_STATUS ("FLTOPS  STATUS  AT  END  OF  RUN:") 

.OUTPUT^ERRORS  ; 
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STATEMENT  := 

IF  STATEMENT 
! 00“STATEMENT 
! INVOKE.STATEMENT 
! INPUT_FILE_PARSIN6_0PERATI0N 
.SET(ERR0R”nUM8ER  * 2) 
ERROR.OPTION 
! FINO.STATEMENT 

.SET(ERROR_NUMBER  » 31) 

ERROR  OPTION 

! SYMeOL_EXISTS_STATEMENT 
.SET(ERROR_NUMBER  * 4) 

ERROR  OPTION 
! TABLeIeMPTY. STATEMENT 
.SET(ERROR  NUMBER  » 3) 
ERROR_OPTION 
! ASSERT.STATEMENT 

.SETCERROR  NUMBER  = 9) 
ERROR_OPTION 
! NODE  EXISTS.STATEMENT 
,SET(ERROR  NUMBER  = 57) 

ERROR  OPTION 

? SAVE  POINTER  STATEMENT 
! RESTORE_POINfER_STATEMENT 
! STATUS.STATENENT 
! ENTER  STATEMENT 
! CATENATE  STATEMENT 
! REPLACE.STATEMENT 
! DELETE  STATEMENT 
! CLEAR  STATEMENT 
! DEFINE_STATENENT 

• SET  STATEMENT 

! INCREMENT.STATEMENT 
! OECREMEMT_STATEMENT 

• MESSAGE  STATEMENT 

! PARAMETERS  STATEMENT 
! EXECUTE_STATEMENT 
! OUTPUT_STATEMENT 
» .FORTRAN 

! "ELSE"  .MESSAGE(49) 

• "THEN"  .MESSAGE(50) 

! .PEEK("ENO")  .FALSE 

• .PEEIC("ENO  OF  FILE")  .FALSE 
! .TRUE  .MESSAGECI)  ; 


I 
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ERROR_OPTION  := 

~.TEST(0PERATI0N_TRUE_FALSE  indicator  = "FALSE") 

( "ERROR"  ":"  .ERROR(17)"  STATEMENT 

! .TRUE 

.(MESSAGE  (ERROR_NUMBER)  ) 

! ( "ERROR"  ":"  7eRROR(17)  .SCAN  TO  LOCATION(I) 

STATE^iENT 
.LOCATION! 1 ) 

? .TRUE  ) ; 


/*  IF  STATEMENT  */ 


IF_SrATLMENT  := 

"IF" 

BOOLEAN_EXPRESSION  .FRROR(32) 

"THEN"  .ERHOR(55) 

.PPCPUSH  OPER  ATION_TRLIE  FALSE  INDICATOR  ONTO  BOOLEAN  TRUTH  STACK) 
( .TEST(OPERATION_fRUE_FALSE^fNDICATOR  = "FALSE") 
.SCAN_TO_LOCATION(1)~ 

• .TRUE  ) 

STATEMENT 
.LOCATION!  1 ) 

.DO!POP  TOP  ELEMENT  FROM  BOOLE  AN _TRUTH _S TA CK  AND  SAVE  AS 
OPERATION  TRUE  F AL SE _ I N D I C A TO R ; ) 

! "ELSE"  /*  OPTIONAL  ELSE  CLAUSE  */ 

! .TEST!0PERATI0N_TRUE_F ALSE  INDICATOR  = "TRUE") 

.SCAN  TO  LOCATION!?)" 

! .true") 

STATEMEN  T 
' .TRUE  ) 

.LOCATION!?)  ; 


/*  DO  STATEMENT  */ 

/****<***^4-*******/ 


DO  ■,  r * f f N T : = 

~ t>o" 

» "FOR"  ! 0O_F0R_SYMri0L_T AHLE 

' oo~for‘each  )“  .ERRORCM) 

• "0  -MILE 

• .I’"Lf_00  ) 
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DO  WHILE  ;= 

"WHILE” 

.RECOVERY.POINT 

POOLEAN  EXPRESSION  .ERRORC32) 

( .TEST(OPERATION_TRUE_FALSE_INOICATOR  = "FALSE”) 
.SCAN  TO_LOCATION(1)' 

• .true”) 

S STATEMENT 

"END"  .ERR0R(20) 

.RETURN_T0_RE cover Y_PO IN T 
.LOCATION(T)  ; 


DO  FOR  SYMBOL  TABLE  :* 

"SYMBOL"  "TABLE"  .ERROR(34) 

.OOTPUSH  CURRENT  DE F AULT.S YM90L _T AB LE  ONTO  DE F AULT _T AB LE _S T A CK ; ) 
.SETTRULE  TABLE_0R_SYM80L_NAME  = "TRUE") 

STRING  EXPRESSION  .ERR0R(35) 

.SET(OEFAULT_SYM80L_TABLE  = **) 

S STATEMENT 

"END"  .ERR0R(22) 

.DO(POP  TOP  ELEMENT  FROM  OE FAULT_TABLE _S TA CK  AND  SAVE  AS 
DEFAULT  SYMBOL.TABLE;) 


DO  FOR_EACH  := 

"EACH"  "SUBNODE"  .ERROR(23) 

"OF"  .ERR0R(36) 

.00(PUSH  VALUE  OF  INPUT_PA RSING^POINTER  ONTO  I NPUT _POI NT ER_S T A CK ; ) 
FIND  INPUT  NODE  .ERROR(54) 

.MOVE  INPUT_POINTER_OOWN 
.SEKBROTHER  NODE_ENO  » "FALSE") 

( .TEST(OPERATIOn”tRUE_FALSE_INOICATOR  = "FALSE") 

.MESSAGE(37) 

.SCAN^TO_LOCATION (1  ) 

• .true”) 

$ ( .TEST<OPERATION_TRUE_FALSE_INOICATOR  = "TRUE") 

.RECOVER Y_P0INT” 

% STATEMENT 

"END"  .ERR0R(24) 

.ADVANCE  INPUT  POINTER 
( .TESTTBROTHER  NOOE.END  = "FALSE") 

. RE TURN_TO_RE COVER Y_POINT 

! .TRUE  TooTpOP  TOP  ELEMENT  FROM  RECOVERY_POINT_STACK ; ) ) ) 
.LOCATIONd) 

.OOTPOP  TOP  ELEMENT  FROM  INPUT_POINTER_S TACK  AND  SAVE  AS 
INPUT  PARSING. POINTER;) 

.SER(BROTHER  NOOE.ENO  » "FALSE")  ; 
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SI«PLE_00  := 

Itrue 

$ STATEMENT 
“END" 


.£RROR(21) 


Z*********************/ 
/*  INVOKE  STATEMENT  */ 
/*********************/ 


INVOKE  STATEMENT  := 

"INVOKE"  t*  FCF  STATEMENTS  ARE 
.SET<RULE_TA8LE  OR  SYMBOL  NAME  » 
STRING.EXPRESSION  ' .ERR0R(38) 
.RECOVERr_POlNT 
.INVOKE!**) 

( .TEST<OPERATION  TRUE  FALSE  INDICATOR 
S STATEMENT 
"END"  .ERROR<39) 

.IDENTIFIER  .ERROR(12) 
.ENO_PROCEOURE(*) 

< .PEEK<"ENO  OF  FILE") 

• .TRUE  .MESSAGEdS) 

$<  STATEMENT  ! "END"  ) ) 

• .TRUE  .MESSAGE(52)  ) 

.RETURN  TO  RECOVERY  POINT  ; 

/*“enO  OF 
/*  END  OF 


NOW  PROCESSED 
"TRUE") 


IN  NAMED  FCF  RULE  */ 


■TRUE") 


FILE  IN  THIS 
THE  RILE  HAS 


CONTEXT  IMPLIES  THE  LOGICAL  */ 
BEEN  FOUND  */ 


/* 

/*^ 


INPUT  FILE  STATEMENTS 


'*/ 

♦/ 

'*/ 


1NPUT_FILE_PARSING. OPERATION  :* 

"INPUT"  ' /*  GET  NEXT  TOKEN  FROM  INPUT  SPECIFICATION  */ 

LEFT^PAREN 

.DOIPUSH  VALUE  OF  INPUT  PARSING.POINTER  ONTO  INPUT  POINTER  STACK;) 
IMPUT.GROUP  .ERRORdS) 

${  "OR"  /*  MULTIPLE  INPUT  INQUIRIES  ARE  POSSIBLE  */ 

( .TEST(OPERATION  TRUE  FALSE  INDICATOR  ■ "TRUE") 

.SCAN  TO  LOCATIONd)" 

» .TRUE  ) 

INPUT  GROUP  .ERRORdS)  ) 

.LOCATIONd) 

RIGHT.PAREN  ; 
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INPUT_GROUP  := 

“input  element 

.SET(FINISH^FLAG  = "FALSE") 

S ( .TEST(F1NISH_FLA6  * "FALSE") 

( .TESTCOPERATION  TRUE_FALSE_I ^OICATOR  = "FALSE") 

.SCAN  TO_LOCATION(1)‘ 

» .true”) 

< INPUT  ELEMENT  ! .TRUE  . SET ( FINI SH.FL AG  » "TRUE")  ) ) 

.LOCATION(1)  ; 


INPUT_ELEMENT  := 

“"CONSTANT" 

.PARSE  INPUT(NUMBER) 

< .TEST <OPERATION_TRUE_FALSE^lNOICATOR  = "FALSE") 

SIGNED  NUMBER 
! .TRUE  “) 

! "NUMBER"  .PARSE_INPUT(NUMBER) 

! "SIGNED  NUMBER"  SI6NED.NUM8ER 

! "WORD"  “.PARSE  INPUT(IDENTIFIER) 

! "STRING"  .PARSE  INPUT (STRING ) 

• .STRING  .DO(PROCESS  FCF_PREVIOUS_SYMPOL  TO  ELIMINATE  DELIMITERS;) 
.PARSE_INPUTC*)  ; 


SIGNED  NUMBER 

ToOCPUSH  INPUT.PARSING.POINTER  ONTO  1NPUT_P01NTER_STACK;) 

.PARSE  INPUTC*-") 

( .TESTCOPERATION  TRUE. FALSE  INDICATOR  = "FALSE") 

.PARSE  INPUT("+") 

! .TRUE  ) 

( .TESTCOPERATION  TRUE.F ALSE.IND IC ATOR  = "TRUE") 

.SETC**  * INPUT”pR£VI0US_SYM80L) 

•PARSE  INPUTCNUMBER) 

( .TEST (OPERATION.TRUE.FALSE.I NDICATOR  = "TRUE") 

.OOCINPUT. PREVIOUS. SYMBOL  = ** ! ! INPU T.PR EV lOUS.SYMBOL; ) 

.OOCPOP  TOP  ELEMENT  FROM  INPUT.POINTER.STACK;) 

! .DOCPOP  TOP  ELEMENT  FROM  INPUT“pOINTER_STACK  AND  SAVE  AS 

INPUT.PARSING.POINTER;)*  ” j 

.TRUE  ) “ “ 

! .TRUE  .DOCPOP  TOP  ELEMENT  FROM  INPUT. POINTER.STACK  AND  SAVE  AS  j 

INPUT  PARSING  POINTER;)  ) ; ” 


FIND  STATEMENT  :* 

"FIND"  /*  POSITIONS  INPUT.PARSING.POINTER  TO  SPECIFIED  INPUT  NODE  */ 
LEFT  PAREN 

.OOCPUSH  VALUE  OF  INPUT.PARSING.POINTER  ONTO  I NPUT.POI NTEP.S TA CK ; ) 

FIND  INPUT  NODE  .ERRORC54) 

( .TESTCOPERATION  TRUE  FALSE  INDICATOR  = "TRUE") 

.DOCPOP  TOP  ELEMENT  FORM  INPUT.POINTER .STACK ; ) 
f ! .TRUE  .DOCPOP  TOP  ELEMENT  FORM  INPUT  POINTER  STACK  AND  SAVE 

i AS  INPUT.PARSING.POINTER;)  ) 

f RIGHT  PAREN  ; 

I * 

I 

I 


I 
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SAVE_POINTER_STATEMENT 

"SAVE.POINTER" 

,DO<PUSH  VALUE  OF  1NPUT_PARSING_P0INTER  ONTO  I NPUT _POI NTER.STACK ; ) 

RESTORE_POINTER_STATE!1ENT  ;* 

"RESTORE  POINTER" 

.DO(POP  TOP  ELEMENT  FROM  INPUT_POINTER_S TACK  AND  SAVE 
AS  INPUT_PARSING_POINTER;) 


/*********************/ 
/*  TEST  STATEMENTS  */ 
/*****«**«************/ 


SYMBOL  EXISTS  STATEMENT  :* 

"SYMBOlIexISTS"  I*  TEST  FOR  PRESENCE  OF  SYMBOL  IN  TABLE  */ 

LEFT  PAREN 

.SETCRULE  TABLE  OR  SYMBOL  NAME  * "TRUE") 

STRING  EXPRESSION  .ERROR(35) 

( .PEEKC’)") 

.FIND  TABLECDEFAULT  SYMBOL  TABLE) 

.testIfor_symbol(**) 

! COMMA 

.FIND_TABLE(**) 

.SET(RULE_TABLE_0R_SYMB0L_NAME  * "TRUE") 

STRING_EXPRESSION  .ERR0R(40)  .TEST_FOR_SYMBOL (*♦)  ) 
RIGHT_PAREN  ; 


TABLE_EMPTY_STATEMENT  :» 

"TABLE  EMPTY"  /*  TEST  FOR  EMPTY  TABLE  */ 

LEFT_PAREN 

.SETCRULE  TABLE_OR_SYMBOL  NAME  » "TRUE") 

STRING  EXPRESSION  ”.ERROR<35)  .FIN0_TA8LE(**) 

< .TESTCSYMBOL  TABLE  POINTER  = NULL) 

.SETCOPERATION  TRUE  TRUE  INDICATOR  = "FALSE") 

• .TRUE  .SET(OPERATION_TRUE_FALSE_IN01CATOR  = "FALSE")  ) 
RIGHT  PAREN  ; 


NODE  EXISTS  STATEMENT  ;= 

"NODE“exISTS"  /*  TEST  FOR  OCCURRENCE  OF  SPECIFIED  INPUT  TREE  */ 
LEFT^PAREN 

.DOIPUSH  INPUT  PARSING_POINTER  ONTO  INPU T_PO I N TER_ST AC K ; ) 
FINO_INPUT  NODE  .ERROR(54) 

.DOCPOP  TOP  ELEMENT  FROM  INPUT  POINTER'S  ^’,CK  AND  SAVE 
AS  INPUT  PARSING  POINTER;) 

RIGHT_PAREN; 


• 'I 


FLTOPS  FUNCTIONAL  DEFINITION  GRAMMAR 


/**********************/ 
/*  ASSERT  STATEMENT  */ 
/*****«****«*«*********/ 


ASSERT_STATEMENT  :* 

MiCCCDT" 

( .TEST(DE0UG  = "OFF"  ) 

.SCAN  TO  LOCATION(I) 

.SETCOPERATION  TRUE  FALSE  INDICATOR  = "TRUE") 


! .TRUE) 

BOOLEAN  EXPRESSION  .ERROR(32) 
.LOCATIONd); 

/********************/ 
/*  STATUS  STATEMENT  */ 
/****************«***/ 


STATUS.STATEMENT  := 

"STATUS" 

< .TESTCDEBUG  = "OFF") 

.SCAN  TO  LOCATIONd) 

! .true”) 

LEFT  PAREN 

.STRING  .ERRORCSS) 

.DOCPROCESS  * TO  REMOVE  DELIMITERS,  THEN  SAVE  AS  HEADING;) 

< .PEEKC")")  .OUTPUT  STATUS (HE ADING ) 

! COMMA  STRING  EXPRESSION  .ERROR(35)  .SET (TABLE.N AME  = *) 

( .PEEK!")")  .DOCWRITE  OUT  HEADING  AND  CONTENTS  OF  TABLE  TABLE.NAME;) 
! ARRAY  ELEMENTS  .GET_VALUE <**) 

.DOCWRITE  OUT  HEADING, TABLE  NAME  AND  CONTENTS  OF  **;) 

! COMMA  STRING  EXPRESSION  .ERROR(AC)  .GET_VALUE<**) 

.00(WRITE  OUT  HEADING, TABLE_NAKE,  CONTENTS  OF  ♦ AND  CONTENTS  OF  **;) 
RIGHT  PAREN 
.LOCATIONd)  ; 
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/*«**«**«**********************************«**«************************/ 
/*««*«**«««**«**  SYMBOL  TABLE  MANIPULATION  STATEMENTS  ******♦****★***/ 
/*****•**«********************************«*****•*****««***«*«*****«***/ 

/*********************/ 

/♦  ENTER  STATEMENT  */ 

/*********************/ 


ENTER  STATEMENT  :> 

"ENTER"  /*  ENTER  VALUES  INTO  SYMBOL  TABLE  */ 
LEFT  PAREN 

LOCATION  POINTER  .ERROR(35) 

( ' /*  VALUE  FIELD  IS  PRESENT  */ 

STRING  EXPRESSION  .ERRORdG) 
(FORMAT.STATEMENT  ! .TRUE) 

.ENTER  VALUE<**) 

! .TRUE  ) 

RIGHT  PAREN  ; 


/*********************★**/ 
/*  CATENATE  STATEMENT  */ 
/***********************«/ 


CATENATE  STATEMENT  :* 

"CATENATE"  /*  PERFORMS  STRING  CATENATION  ON  VALUE  FIELDS  */ 
LEFT^PAREN 

LOCATION.POINTER  .ERROR(35> 

S ( STRING. EXPRESSION  .ERRORdA) 

(FORMAT. STATEMENT  ! .TRUE) 

.CATENATE.VALUE(**)  ) 

RIGHT.PAREN  ; 

/*************«*********/ 

/*  REPLACE  STATEMENT  */ 

/***********«***********/ 


REPLACE  STATEMENT  :« 

"REPLACE"  /*  PERFORMS  SUBSTRING  REPLACEMENT  */ 
LEFT.PAREN 

LOCATION  POINTER  .ERROR(35) 

( .PEE<(")")  .MESSAGE(A2) 
f COMMA  STRING  EXPRESSION  .ERRORdA) 

.SET(STRING1  a"**) 

COMMA  STRING. EXPRESSION  .ERRORdA) 
(FORMAT.STATEMENT  ! .TRUE) 

.S£T(STRING2  * **) 

.SETCNUMBER  REPLACES  * INFINITY) 

< ARITHMETIC. EXPRESSION  .ERRORdA) 

.SETCNUMBER  REPLACES  * **) 

! .TRUE  ) 

. REPLAC E. ST R IN6(STRING1,STR I NG2, NUMBER. REPLACES)  ) 
RIGHT.PAREN; 
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/**«***********«*****«*/ 
/*  DELETE  STATEMENT  */ 
/*************«********/ 


DELETE  STATEMENT  :* 

"DELETE"  /*  DELETE  ENTRY  FROM  SYMBOL  TABLE  */ 

LEFT_PAREN 

•SETIRULE  TABLE. OR  SYMBOL. NAME  ■ "TRUE") 

STRING  EXPRESSION  ”.ERROR(35)  . FIND.TABLEI**) 

( .PEEXC)') 

.FIND  TABLE (DEFAULT.SYMBOL.TABLE) 

,TEST“fOR  SYMBOL!**) 

( .TEST<OPERATION  TRUE.FALSE.INDICATOR  « "TRUE") 
.DELETE.ENTRY 
! .TRUE  ) 

! .TRUE 

.FIND  TABLE!**) 

! .PEEK!"!") 

ARRAY.ELEMENTS 

.00!P0P  TOP  ELEMENT  FROM  SUBSCRIPT. COUNTER.STACK  AND 
SAVE  AS  STACK  SIZE;) 

. COMPUTE. TABLE.POSITION 

.FIND  8y”sUBSCR1PT!ARRAY.POSITION) 

! comma"  .SET!RULE  TABLE.OR  SYMBOL  NAME  * "TRUE") 
STRING.EXPRESSION  .ERR0R!40) 

.TEST  FOR  SYMBOL!**) 

! .TEST!OPERATION  TRUE  FALSE  INDICATOR  » "TRUE") 
.DELETE.ENTRY 
! .TRUE  ) ) ) 

RIGHT_PAREN  ; 

/*******'********'******/ 

/*  CLEAR  STATEMENT  */ 

/*******«*************/ 


CLEAR  STATEMENT  := 

""CLEAR  TABLE"  /*  DELETE  ALL  ENTRIES  IN  TABLE  */ 

LEFT.PAREN 

.SET!RULE  TABLE  OR  SYMBOL  NAME  * "TRUE") 

STRING  EXPRESSION  .ERR0R!35)  .FIND.TABLE!**) 

RIGHT  PAREN 

$!  .TEST!SYMBOL  TABLE  POINTER  NOT  NULL)  .DELETE.ENTRY  ); 


/*****««*******«'*««**«*/ 

/*  DEFINE  STATEMENT  */ 

f *********  It*****  ******* / 


DEFINE  STATEMENT  :» 

"DEFINE"  /*  SETS  UP  TABLES  THAT  CAN  BE  ACCESSED  VIA  SUBSCRIPTS  */ 
.SET!RULE  TABLE  OR  SYMBOL.NAME  ■ "TRUE") 

STRING  EXPRESSION  " .ERROR!35) 

.SETIDEFINE  TABLE  NAME  » ♦*  ) 

DEFINED  ELEMENT  ".ERR0RC59) 

S ! .SET!RULE  TABLE  OR  SYMBOL  NAME  » "TRUE") 

STRING  EXPRESSION  .ERROR!3S) 

.SET(0EFINE.TA8LE.NAME  » **  ) 

DEFINED  ELEMENT  .ERR0R!S9)  ); 
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DEFINED  ELEMENT  :« 

ARRAY  ELEMENTS 

.ARRAY  SETUPIDEFINE  TABLE.NAME) 

! "AS"  “ /*  DEFINE  TABLE  EQUIVALENCE  •/ 

( "null”  /*  ELIMINATE  EQUIVALENCE  AND  REMOVE  DIMENSIONS  */ 
.NULL  OUT.TABLE<OEFlNE_TABLE_NAME) 

! .SETIRULE  TABLE  OR  SYMBOL.NAME  » "TRUE") 

STRING  EXPRESSION 

.SETIEQUIVALENCED  TABLE_NANE  ■ **) 

•SETUP  TABLE  EQUIVALENCE 
! .TRUE  .MESSAGE(27)  ) ; 


/*******************/ 
/♦  SET  STATEMENT  */ 
/*******************/ 


SET  STATEMENT  :*  I*  SHORTHAND  FORM  OF  THE  ENTER  STATEMENT  */ 

"SET"  LEFT  PAREN  /*  SET  SYMBOL  TO  INDICATED  VALUE 

.SET(RULE_TABLE_0R_SYM80L_NAHE  » "TRUE") 

STRING  EXPRESSION  .ERR0R?40) 

.FlNO_fABLE<OEFAULT_SYMBOL_TA8LE) 

.FIND“oR  enter  SYMBOL!**) 

( “/*  OPTIONAL  ARITHMETIC  ASSIGNMENT  STATEMENT  */ 

.SAVE.POINTER 

STRING  EXPRESSION  .ERROR(54) 

(FORMAT  STATEMENT  ! .TRUE  ) 

.RESTORE  POINTER 
.ENTER_VALUE(**) 

! .TRUE  ) 

RIGHT_PAREN; 


/•************************/ 
/*  INCREMENT  STATEMENT  */ 
/•*******«*******«***«****/ 


INCREMENT  STATEMENT  :* 

"INCREMENT"  LEFT_PAREN  /*  INCREMENT  SWITCH  VALUE  BY  ONE  */ 

.SETIRULE  TABLE  OR  SYMBOL  NAME  « "TRUE") 

STRING  EXPRESSION  * .ERR0R(40) 

.FIND,TA3LE(OEFAULT_SYMBOL_TABLE) 

.FINO~OR_ENTER_SYMBOL(**) 

.GET  VALUE!**)” 

.00!ADD  1 TO  TEHPORARY_STRING;  NOTE  THAT  STRING  MUST  BE  TREATED  AS 
ARITHMETIC  VALUE;  IF  STRING  IS  NULL,  TREAT  AS  ZERO;) 
.ENTER_VALUE!**)  RIGHT_PAREN; 
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/«******«****«************/ 
/*  OECRENENT  STATEMENT  */ 
/************««***********/ 


DECREMENT  STATEMENT 

"DECREMENT"  LEFT.PAREN  /*  DECREMENT  SWITCH  VALUE  BY  ONE  */ 

.SETIRULE  TABLE  OR.SYMBOL.N AME  » "TRUE") 

STRIN6.EXPRESS10N  .ERR0R(40) 

,F1ND,0R_ENTER.SYM80L(**) 

.GET  VALUE!**) 

.DOCSUBTRACT  1 FROM  TEMPORARY.STRING;) 

.ENTER  VALUE!**)  RI6HT_PAREN  ; 


/****«**««*****«***«*«**«***«*******«******«***#***************««******«/ 
/****«******«*****  end  OF  TABLE  MANIPULATION  STATEMENTS  ♦***#♦******♦*/ 


********************************************************  ********/ 


/***  It*  ■kn  *******************  ******/ 

/*  BUILT  IN  FUNCTIONS  */ 

/********************************/ 


f**********************/ 

/*  INDEX  FUNCTION  */ 

/**********************/ 


INDEX  FUNCTION  :*  /*  DETERMINE  STARTING  POSITION  OF  SUBSTRING  */ 

■"INDEX" 

LEFT  PAREN 

.INCREHENT!ARITH  DEPTH  COUNTER) 

STRING  EXPRESSION  .ERROR!14) 

.SET!STRIN61  * **) 

COMMA  STRING  EXPRESSION  .ERR0R!14) 

.SET<STRIN62  = **) 

. INDEX CSTRIN61, STRINGS, START_POS) 

.OECREMENT!ARITN  DEPTH.COUNTER ) 

RIGHT  PAREN  ; 


/************************/ 
/*  LENGTH  FUNCTION  */ 

/************************/ 


LENGTH  FUNCTION  :>  /*  DETERMINE  THE  LENGTH  OF  A STRING  */ 

"LENGTH" 

LEFT.PAREN 

.INCREMENT !AR1TH.DEPTH.C0UN TER) 

STRING  EXPRESSION  .ERR0R!14) 

.LENGTH!**, STRING  LENGTH) 

.OECREMEMT!ARITH  OEPTH.COUNTER ) 

R1SHT_PAREN  ; 
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{■ 


/************************/ 
/*  SUBSTRING  FUNCTION  */ 
/««««*««**«**************/ 


SUBSTRING  FUNCTION  :« 

"SUBSTRING"  /*  GET  SUBSTRING  FROM  INDICATED  STRING  */ 
LEFT_PAREN 

STRING  EXPRESSION  .ERROR(58) 

.SETCSTRING  IN  « **) 

CONNA  ARITHMETIC.EXPRESSION  .ERR0R(A7) 

,SF, (START  POS  » COMPUTED  VALUE) 

( ","  ARITHMETIC  EXPRESSION  .ERR0R(A7) 

.SUBSTRING(STRINS_IN,**,START_POS,CCMPUTED_VALUE) 

! .TRUE 

.SUBSTRING(STRING_IN,**^START_POS,0)  ) 

RIGHT  PAREN  ; 


/*********************/ 
/*  VALUE  FUNCTION  */ 
/***«************«**** / 


VALUE  FUNCTION  :* 

""VALUE"  /*  RETRIEVE  VALUE  FROM  DESIGNATED  PLACE  ♦/ 

LEFT  PAREN 

( "3"  /*  SYMBOL  TABLE  POINTER  ALREADY  SET  ♦/ 

! ,SET(RULE  TABLE  OR_SYHBOL_NAHE  = "TRUE") 

STRING  EXPRESSION 
.SAVE  POINTER 

( .PEEK(")")  .FINO_TA8LE{DEFAULT_SYMBOL_TABLE) 

.FIND  OR  ENTER  SYMBOLC**) 

! ","  .FIN0_TABLE(**) 

.SEKRULE  TABLE  OR  SYMBOL  NAME  » "TRUE") 
STRING.EXPRESSION  .ERR0R<40) 

.FIND  OR  ENTER  SYMBOL(**) 

• .PEEK("(") 

.FIND  TABLE(**) 

array"elements 

.0O(POP  TOP  ELEMENT  FROM  SUBSCRIPT_COUNTER_STACK  AND 
SAVE  AS  STACK  SIZE;) 

.COMPUTE  TABLE_POSITION 

.FIND  By"sUBSCRIPT<ARRAY  POSITION) 

! .TRUE  .NESSAGE(35)  ) 

.SET<VALUE_LOCATION  » SYMB0L_TABLE_P01NTER ) 

.GET  VALUE!**) 

.RESfORE.POlNTER 
RIGHT.PAREN  ; 
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/*****************«*****/ 

/♦  MESSAGE  STATEMENT  *t 
/*****«***********^*****/ 


MESSAGE  STATEMENT  :* 

"MESSAGE"  LEFT.PAREN 
STRING  EXPRESSION  .ERROR(26) 

(FORMAT  STATEMENT  * .TRUE) 

.SET(MESSA6E  « ♦*) 

.DOCCHECK  FIRST  TWO  CHARACTERS  OF  MESSAGE  FOR  LEGAL  TYPE 

AND  SEVERITY  LEVEL;  IF  EITHER  NOT  VALID  THEN  OUTPUT 
WARNING  TO  THAT  EFFECT;  CATENATE  GW:  TO  START  OF  MESSAGE;) 
S ( STRING  EXPRESSION  .ERR0R(26) 

(FORMAT  STATEMENT  ! .TRUE  ) 

.00(MESSAGE  > MESSAGE !• TEMPORARY.STR ING; ) ) 

.MESSA6E(MESSAGE)  RIGHT.PAREN  ; 


/****#******************«*********«*««*«/ 
/*  EXECUTE  AND  PARAMETERS  STATEMENTS  */ 
/************#***********«**********«***/ 


PARAMETERS  STATEMENT  :* 

"PARAMETERS" 

.IDENTIFIER  .ERR0R(44) 

.SET(EXECUTE_ROUTINE_NAME  * "$"!!*) 

.SET(PARAMETER  COUNT  = 1) 

LEFT  PAREN  PARAMETER  TYPE  .ERROR(IO) 

.FIND  TA8LE(EXECUTE  ROUTINE.NAME) 

.00(ENTER  VALUES  FOR  PARAMETER_CLASS  AND  PARAMETER. SIZ E INTO  TABLE 
IN  POSITION  INDICATED  BY  PARAMETER.COUNT; ) 

S ( .INCREMENT(PARAHET£R.COUNT) 

PARAMETER  TYPE  .ERROR(IO) 

.FIND  TABLE(EXECUTE.ROUTINE_NAME) 

.OOCENTER  VALUES  FOR  PARAMETER.CLASS  AND  P AR AMETER.SIZE  INTO  TABLE 
IN  POSITION  INDICATED  BY  PARAMETER. COUNT; ) ) 

RIGHT.PAREN  ; 
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PARAMETER  TYPE  := 

( "REAL"  ! "INTEGER"  ! "ALPHA"  ! "LOGICAL"  ! "DOUBLE"  ) 
.SET(PARA,1ETER_CLASS  = *) 

.set(paraiieter”size  « 1) 

{ .PEEK<"(") 

.SET(POSITION_VALUE  = 1) 

ARRAY  ELEMENTS 

.00<COMPUTE  PRODUCT  OF  ELEMENTS  IN  ARRAY_STAC<  AMO 
SAVE  AS  ARRAY_POSITION;) 

.SET(PARAMETER  SIZE  * ARRAY  POSITION  ) 

! .TRUE  ) ; 

EXECUTE  STATEMENT  := 

"EXECUTE"  /*  EXECUTE  A ROUTINE  TO  DETERMINE  PRECOMPILE  TIME  VALUES  */ 
.IDENTIFIER  .ERR0R(44) 

.SET(EXECUTE  ROUTINE_NAME  * "S"!!*) 

LEFT  PAREN  7s ET (PARAMETER  COUNT  * 1) 

.DO(SET  EXECUTE  DATA_AREA_POINTER  TO  LAST  LOCATION  IN  EXECUTE.DATA.AREA 
THAT  HAS  RECEIVED  DATA;) 

EXECUTE  PARAMETER  .ERROR(45) 

% ( .1NCREMENT(PARAMETER_C0UNT) 

EXECUTE  PARAMETER  .ERROR(45)  ) 

RIGHT  PAREN*  .EXECUTE (EXECUTE  ROUTINE  NAME) 

.SET(CONVERT  FLAG  = "OUT") 

.EXECUTE  PARAMETER  UPDATE  ; 


EXECUTE  PARAMETER  := 

.SET(PARAMETER  LOCATION  = NULL) 

.SET(ARITH_DEPfH  COUNTER  = 0) 

.SET(ARITH_OPERATOR_FOUND  = "FALSE") 

( .STRING  “ .00(PROCESS  FCF  PREVIOUS  SYMBOL  TO  REMOVE  DELIMITERS 

THEN  COPY  INTO  TEMPOR ARY_STRING; ) 

• ARITHMETIC  EXPRESSION 

.00(P0P  TOP  ELEMENT  FROM  ARITHMETIC  STACK;) 

( .TEST(ARITH  OPERATOR.FOUND  » "FALSE") 

.SET(PARAMETER  LOCATION  > VALUE  LOCATION) 

• .TRUE  ) ) 

.FINO_TABLE(£XECUTE_ROUTINE_NAME) 

.TESTThaS  PARAMETER“inFORMATION  BEEN  ADDED  TO  TABLE;)  .ERROR(51) 
.00(F0R  ARGUMENT  IDENTIFIED  BY  P AR AM ET ER _COUNT  ENTER  PARAMETER  LOCATION 
AND  RETRIEVE  VALUES  FOR  PARAMETER^CLASS  AND  PARAMETER  SIZE;) 
.SET(CONVERT  FLAG  * "IN") 

.EXECUTE.DATA  AREA  UPDATE; 
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/**********************/ 
f*  OUTPUT  STATEMENT  */ 
/***************«***★**/ 


OUTPUT  STATEMENT  :» 

"OUTPUT"  LEFT  PAREN 
OUTPUT  ELEMENT  .ERROR(46) 

$(  OUTPUT.ELEflENT  .ERR0R(A6)  ) 

RIGHT  PAREN  ; 


OUTPUT  ELEMENT  ;■ 

.LABEL  .OOCPLACE  CORRESPONDING  GENERATED  STATEMENT  NUMBER  IN 
TEMPORARY.STRING;) 

.OUTPUT!**) 

• .OUTPUT(STATEMENT  TERMINATOR) 

, («eoF"  ! -END  OF.FILE") 

.00<IF  OUTPUT’bUFFER  non  EMPTY  THEN  OUTPUT  ITS  CONTENTS; 

THEN  OUTPUT  END  OF  FILE  MARK;) 

! ("EOR"  ! "END  OF  RECORD") 

.DOtlF  0UTPUT"8UFFER  IS  NON-EMPTY  THEN  OUTPUT  ITS  CONTENTS; 
THEN  OUTPUT  END  OF  RECORD  MARK;) 

! COLUMN  FORMAT 

! ("COMMENT"  ! "C")  .SET(**  = *) 

";"  .ERR0R(17) 

.SET(OUTPUT.COMHENT_CARO  » "TRUE") 

.OUTPUT!**)” 

! STRING  EXPRESSION 

(FORMAT.STATEMENT  ! .TRUE) 

.OUTPUT!**)  ; 


COLUMN  FORMAT  :«  /*  ADJUST  COLUMNS  */ 

("COL"  ! "COLUMN") 

LEFT  PAREN 

ARITHMETIC  EXPRESSION  .ERR0R!47) 

.00!P0P  TOP  ELEMENT  FROM  ARITHMETIC_STACK;) 
.ADJUST.COLUMN!**) 

RIGHT.PAREN  ; 
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FORMAT  STATEMENT  :*  /*  FORMATTED  OUTPUT  *! 

? "FORMAT"  .SET(STRING_IN  » ♦*) 

LEFT  PAREN 

FORMAT  ELEMENT  .ERR0R(6C) 

RIGHT  PAREN 

! ”a>"  .SETCSTRING.IM  « *•) 
FORMAT_ELEHENT  ,ERR0R<60)  ) 
,FORMAT_STRING(STRING.IN,**)  ; 


FORMAT  ELEMENT  :* 

VALUE  FUNCTION 
! .IDENTIFIER  .SET(**  ■ *) 

< .NUMBER  .DOCTEMPORART  STRING  » TEMPORARY  STRING  !!FCF  FREVIOUS  SYMBOL;) 
• .TRUE  ); 


/**************«*************/ 

/*  ARITHMETIC  EXPRESSIONS  */ 

/A*****'*************'********'*/ 


ARITHMETIC  EXPRESSION  :» 

( .T£ST(ARITH_ELEMENT_FOUND  = "TRUE") 

ARITHMETIC  TERM 
! ( ARITHMETIC  TERM 

! ARITHMETIC  TERM  .DOCCHANGE  SIGN  OF  TOP  ELEMENT  OF  ARITHMETIC  STACK;) 

( .TESKARITH  DEPTH  COUNTER  * 0) 

.SETCARITH  OPER ATOR.FOUNO  = "TRUE”) 

! .TRUE  ) 

! ARITHMETIC.TERM  ) ) 

S ( ("♦"  ! ) .DOCPUSH  FCF_PR£VIOUS_SYMBOL  ONTO  OPE RATOR.STACK; ) 

ARITHMETIC.TERM  .ERR0R(T6) 

.COMPUTE  VALUE  > 

( .TESTCPARENTHESIS  COUNT  = 0) 

! .TEST(ARITH_PAREN  = 0) 

( ")"  .OECREMENT(PAR£NTHESIS_COUNT) 

C .PEEKC"*"  ! * •**■*'•  • "»'•  • '•/”  ! ")") 

.SET(ARITH_ELEMENT_FOUNO  * "TRUE") 

.SET(ARITh“vALUE  STORED  * "TRUE") 

arithmetic'expression 

! .TRUE  ) 

! .TRUE  ) 

! .TRUE  ) ; 


ARITHMETIC_TERM  := 

ARITHMETIC_FACTOR 

S ( ( \ "/"  ) .DOCPUSH  FCF_PREVI0US_SYMB0L  ONTO  OPERATOR  STACK;) 

< .TESKARITH  DEPTH  COUNTER  = 0)  " 

.SETCARITH  OPERATOR  FOUND  = "TRUE") 

• .TRUE  ) 

ARITHMETIC_FACTOR  .ERRORdO) 

.COMPUTE.VALUE  > ; 
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ARITHMETIC.FACTOR  :« 

ARITHMETIC  PRIMARY 

( -**••  .OOCPUSH  FCF  PREVIOUS  SYMBOL  ONTO  OPERATOR_STA  CK;) 
( .TESTCARITH  0EPTH_C0UNTER“=  0) 

.SETIARITH  OPERATOR  FOUND  = "TRUE”) 

! .TRUE  ) 

ARITHMETIC.FACTOR  .ERR0R(16) 

•COMPUTE.VALUE 
! .TRUE  ) ; 


ARITHMETIC  PRIMARY  :» 

.INCREMENT(ARITH_PAREN) 

ARITHMETIC  EXPRESSION  .ERR0R(47)  ")"  .ERR0RC28} 

.OECREMENTCARITH  PAREN) 

! ( .TEST(ARITH  ELEMENT.FOUNO  » "TRUE") 

.SET(ARITH_ELEMENT_FOUNO  ■ "FALSE") 

! VALUE  FUNCTION 
! INDEX.FUNCTION 

( .TESTCARITH  DEPTH.COUNTER  = 0) 

.SETIARITH  OPERATOR  FOUND  ■ "TRUE") 

! .TRUE  ) 

! LENGTH  FUNCTION 

( .TEsflARITH  DEPTH.COUNTER  = 0) 

.SEKARITH  OPERATOR  FOUND  * "TRUE") 

! .TRUE  ) 

! .NUMBER 

( .TESTCARITH  DEPTH.COUNTER  » 0) 

.SETIARITH  OPERATOR_FOUNO  = "TRUE") 

! .TRUE  ) 

.OOCCOPY  FCF  PREVIOUS  SYMBOL  INTO  TEMPORARY_STRING; ) 

• .IDENTIFIER 

INDIRECT  LOCATION  POINTER  ) 

( .TEST<ARiTH_VALUE_STOREO  = "FALSE") 

.OOCPUSH  **  ONTO  ARITHMETIC  STACK;) 

• .TRUE  .SET<ARITH_VALUE_STORED  = "FALSE")  ) ; 

ARRAY  ELEMENTS  := 

*"("  .DOIPUSH  1 ONTO  SUBSCRIPT_COUNTER_STACK;) 

.SAVE  POINTER 

.INCREHENTCARITH  OEPTH.COUNTER ) 

ARITHMETIC  EXPRESSION  .ERR0R(48) 

.oecrement7arith.depth_counter) 

.OOISAVE  COMPUTED  VALUE  ON  ARRAY.STACK ; ) 

.DOIPOP  TOP  ELEMENT  FROM  AR ITHMETIC.ST ACK; ) 

$ ( ","  .DOIADD  1 TO  TOP  ELEMENT  OF  SUBSCR IPT_COUNTER .STA CK; ) 
. INCREMENT (ARITH.DEPTH.COUNTER) 

ARITHMETIC  EXPRESSION  .ERR0R<48) 

.DECREMENtTaRITH.DEPTH  COUNTER) 

.DOCSAVE  COMPUTED  VALUE  ON  ARRA Y_STA CK; ) 

.DOCPOP  TOP  ELEMENT  FROM  ARI THMETIC_STACK; ) 

")"  .ERR0R(28) 

.RESTORE  POINTER; 
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/*******«*******•«********/ 

/*  BOOLEAN  EXPRESSIONS  */ 

/«********#***************/ 


BOOLEAN  EXPRESSION  := 

.SET(PARENTHES1S_C0UNT  » 0) 

INPUT  FILE  PARSING.OPERATION 
• BOOLEAN  STATEMENT 

.DO(POP~TOP  ELEMENT  OF  BOOLEAN_TRUTH_STACX  AND  SAVE 
AS  OPERATIONS_TRUE_FALSE. INDICATOR;)  ; 


BOOLEAN.STATENENT  := 

BOOLEAN^PRIMARY 

t < "AND"  BOOLEAN.PRIHARY  .AND 
! "OR"  BOOLEAN  PRIMARY  .OR  ) 


BOOLEAN  PRIMARY  := 

••("  . INCREMENT  (PARENTHESIS.COUNT) 

BOOLEAN, STATEMENT  .ERROR(32) 

( .TEST(PARENTHESIS_COUNT  = 0) 

! .TRUE  ")"  .ERR0R(28) 

.OECREMENT(PARENTHESIS_COUNT)  ) 

• "NOT"  BOOLEAN_STATEMENT  .ERR0R(32)  .NOT 
! BOOLEAN  ELEMENT 

( .TEStTrELATIONAL, EXPRESSION  » "TRUE") 

J »_«  , • t.>s»  I »<B»  I ••<>»  ) 

.ERROR  (1 1 ) 

.SETCRELATICN  TYPE_FLAS  = ♦) 
.SET(SAVEO_VALUE  »"tEMP0RARY_STRIN6) 
BOOLEAN  ELEMENT 

.SET(RELATIONAL_EXPRESSION  * "FALSE") 
,300LEAN_C0MPARE 
• .TRUE  ) *.SAVE_TRUTH  ; 

800LEAN_ELEMENT  ;= 

SYMB0L_EXISTS_STATEMENT 

• TABLE  EMPTY, STATEMENT 

• NODE  EXISTS^STATEMENT 
! FINO'STATEMENT 

! STRING. EXPRESSION 

.SET(RELATI0NAL_EXPRESSI0N  * "TRUE")  ; 
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/*  STRING  EXPRESSION  •/ 


STRING.EXPRESSIOiV  :• 

7alu£_RUNCTION 

( .PEE<(“*"  • • "•*") 

.SET<ARITH_ELEMeNT_FOUNO  ■ "TRUE")  i 

ARITHMETIC  EXPRESSION  i 

.CO(POP  TOP  ELEMENT  FROM  ARITHMETIC  STACX;) 

! .TRUE  > 

• SUSSTRING.FUMCTION 

! (LENGTH. FUNCTION  ! INDEX. FUNCTION) 

.SET(ARITH  ELEMENT  FOUND  ■ "TRUE") 

ARITHMETIC. EXPRESSION 

.00<POP  TOP  ELEMENT  FROM  AR ITHMCTI C.ST ACK; > 

! .IDENTIFIER  .DOiCOPT  FCF  PREV I0US.SYP60L  INTO  TEMPCK AR T.STRING; ) 

( .TEST(RULE  TABLE.OR  SYMBOL  NAME  • "TRUE")  j 

.setirule.table.or.stmbol.name  ■ "FALSE")  ; 

! INDIRECT  LOCATICN.POINTEP 

.SET(ARITH  ELEMENT  FOUND  ■ "TRUE") 

arithmeticIexpression  ‘ 

.DO(»OP  TOP  ELEMENT  FROM  ARITHMETIC.ST ACK; ) 

! .SETCRULE  TABLE.OR  SYMBOL  NAME  ■ "FALSE") 

.STRING  .DOCPROCESS  STRING  IN  FCF.PR EV  lO'JS.S YMBOL  TO  REMCVE  DELIMITERS 
THEN  COPY  INTO  TEMPORARY.STBING; ) 

! "*"  .OOCCOPY  INPUT.PREVIOUS  SYMBOL  INTO  TEPPORARY.STP ING; ) 

» ARITHMETIC.EXPRESSIOM 

.OOCPOP  TOP  ELEMENT  FORM  ARITHMETIC  STACK;)  ; ! 


/•  INPUT  FILE  EXPRESSIONS  */ 


FINO  IN»UT  NODE  :■ 

•SEtThROTHER  node  end  ■ "FALSE") 

.SET<FINISH.FLAG  ■ "FALSE") 

( "3"  /*  USE  CURRENT  VALUE  OF  INPUT  POINTER  •/ 

.SETtOPERATION.TRUe  FALSE  INDICATOR  • "TRUE") 

( "."  .MOVE.INPUT.POIMTER  DOWN 
.IDENTIFIER  .ERRORCSi) 

! .TRUE  .SETCFINISH  FLAG  » "TRUE")  ) 

! .IDENTIFIER 
.HOME. INPUT  ) 

* ( .TEST(FINISM.FLA6«"FALS£") 

FIND.NODE.THIS.LEVEL 
( "."  .MOVE.INPUT.POINTER.DOWS 
.IDENTIFIER  .ERR0R(S4) 

! .TRUE 

.SET(FINISH.FLAS»"TRUE")  ) ) ; 

FLTOPS  FUNCTIONAL  DEFINITION  GRAMMAR 


INDIRECT  LOCATION  POINTER  :■ 

.SAVE.POIHTER 
( .PEEK<"(") 

•FIND.TABLEI"*) 

ARRAY  ELEMENTS 

.00(POP  TOP  ELEMENT  FROM  SUBSCRIPT  COU NT ER .S TA CK  ANt 
SAVE  AS  STACr.SIIE;) 

.COMPUTE  TABLE.POSITION 
.FI NO. BY. SUBSCRIPT (ARP AY  POSITION) 

! .TRUE 

.FIVD.TA3LB(DEFAULT  symbol  TABLE) 
.Fr.D.OR.ENTCR.SYM60L(«»)  ) 

.GET_vALJE(««) 

.SEYrVAL'JE.LOCATICN  • SY'*EOL  TABLE  POIMES) 

.RESTORE  POINTER  ; 


FLTOPS  FUNCTIONAL  DEFINITION  GRAMMAR 


FIND  NODE  THIS  LEVEL  :> 

< .TEST(FLTOPS  FUNCTION  « TEST  OR  FULL) 

•SETIFOUNO  FLAG  ■ "FALSE") 

• .TRUE  .SET (F0UN0_FLA6  » "TRUE")) 

$ ( .TEST(F0UN0_FLA6«"FALSE") 

.PARSE  INPUT!*) 

( . TES T (OPER AT lON.TRUE. FALSE .INDICATOR*" FALSE") 
.ADVANCE.INPUT.POINTER 
C .TEST(8R0THER  NODE  END  ■ "TRUE") 

.SET(FOUNO  FLAC»"TRUE"> 

! .TRUE) 

! .SET(FOUNO.FLAG  « "TRUE") 

.TRUE  ) ) ; 


/**********«*******/ 
/*  MISCELLANEOUS  */ 
/********•***#*****/ 


LEFT.PAREN 
• .TRUE 


.nESSAGE(S)  ; 


RIGHT.PAREN 

“f.  j •• 

! .TRUE 


.MESSAGE(6)  ; 


COMMA  :* 

H M 

! .TRUE  .MESSAGE!?)  ; 


LOCATION.POINTER  :» 

.1 


! "DEFAULT" 

.SET!RULE.TA8LE_OR_SYMBOL_NAME  * "TRUE") 

STRING  EXPRESSION  ~.ERROR!40) 

.FIND  TA8LE!OEFAULT.SYMBOL_TABLE) 

.find"or_enter_svmbol!**) 

! .SET!RULE  TAB LE.OR.SYMBOL.NAME  « "TRUE") 

STRING.EXPRESSION  “.FINO.TABLE!**) 

! TsETIRULE  table  or  symbol  name  * "TRUE") 

STRING  EXPRESSION  7eRR0R!40)“  . FINO.OR.ENTER.SYMBOL !**) 
• ARRAY  ELEMENTS 

.DOIPOP  TOP  ELEMENT  FROM  SUBSCRIPT. COUNTER.STACK  AND 
SAVE  AS  STACX.SIZE;) 

. COMPUTE. TABLE.POSI TI ON 

.FIND  BY.SUBSCRIPT! ARRAY  POSITION) 

! .true”  TmESSAGECAC)  ) 
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U.  j.l 


<stao 


iynuctu:  of  fCr  j6kCM«nc  Typas 

CEPlNlTTOt  OP  SYMRU 
> a ^apMC  Mco  0(  aoc* 

*>■  a TtM  ooUac  awn  la  an  actual  cnaractac  caac.  Crca  ena  PCP 

I a raqiCAi  ‘OR*  ay«D0l 

(...)  a Salact  ana  ican  wtcAlr.  bracaa 

l...i  a icaM  uitAin  bcackata  aca  optional 

(...>  a i^Coca  to  anocnac  cula.  Mrda  oc  ciiacactaca  not  appaacinq 
wit&in  ana  othat  tnan  ttM  apaclai  chacactata  oaCtnao 
naca.  tea  caad  tea;  tna  PCP. 

SrftRCTK  OBSCRtFtXCN 
la  AKSSStr  <booi_aa>  i!NnKi  tatao) 

la  catBRatS«locacion>.iaulnqjix>  *l.<attlnqjta'  i<tontat_at')  1) 
:a  CLEMJMLEKCabla>) 

:a  cacraHCn  Kayaibol^) 

la  dspins  tcabia><aubaccipca>  {|.<eabla><aubacripca>) 
la  CSPTNS  <ca01a'>  AS  ittabla'  I NOLL) 

;a  D8LSTeKta&ia>  i.<ay«boi>  I <aubacclpca'»)) 

:«  DEL?TE|<ayiaaol>) 

:a  cn  »<atat>  S)0 

la  00  foR  3SAai  sasNOoe  CP  <irput_uaa'  $<ac»t'  ^ 
la  00  rOR  SYMBOt.  tASLC  <tabia>  $<atac>  90 
;a  00  MlCS  <Oooi_aa>  ><aut^  SO 
:a  svre.Rdiocacton'^  l,<atiln9jtx'>  (<(ocaac_tt'>|  1) 

:a  oUBCTte  tia'  ii<attinq'  l <.atiu»_aa')  S(,  xattinq'  ! 
<a(it&_aa>)|) 

la  plNCtvinput_uaa'|  lERRRR)  <ata01 
>a  <torccan_atBt> 

ta  tP  <eaoijtx>  «8N  <aaie»  t£.S>  <at»t') 
sa  iN02Rerr«ayBboi» 

:a  iNP'JTuirputjjtp'  iiOR  <inputj;rp'|)  iSWORi  ttcat'i 
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:«  INVOKE  <aulnq_«x> 

i-  MBSS«CSll(ttGlUtf(mGSeML),J<KCrxnq>  $i. 

<SCIU)qjM>  |<tOCMt_at>|l) 

t*  NOOB_SXI&1Si<inpuC_traa'>)  |BM)OR:  <atac>j 

>■  ounuri<oucputjtl>  $(  . <outputjil>l) 

>«  MNMCTBKS  <id>  l<typa'>  $(.<typt>)) 

im  KSKACBl<locacion>.<atiingjta>.<atrinq_aa'>  (<fontat_ar.>| 
l.<ar1thjix'>)) 

!■  MSSTORB_niNTBR 
I-  sKVB^JOiwreR 

:■  bBT(<ayBbol>  I*  <aulnq_ax'>  l<focBat_at'>| ) ) 

;■  S‘tATaS|<acilnq'>  |t><tabla>  I «<cabla'><aubacrlpca'>  i .<ubla> 


<.uioax_tt\> 
<iang  tn_tn' 
<auMcruiq_tji'> 
<v*iua_tn) 
<uol«> 

<iacation> 
<auoaci  ipts"* 
«yf«> 

<input_cia«> 

<.atcinqjax> 

«input_9cp> 

<■  uipuc_ai  > 


Aavotni^ll) 

:•  SYfwX_BXlSTS(l<tabi«'>.l<aya<»X'>)  1S«0R:  <aaBC'k| 

:■  taBIZ_EHmi<cabla'>)  |0«i»i  <atBt'>| 
i • VMOEX  Kau  v«t9_a»N , <.atr 
:■  tE^CTH|<atIi^9_ax>> 

:*  saBSTRINCKauinq_M'>.<atith_ax'>  U<aclchjtx>|) 

:•  vaL3Bm9  1 <ayntol>  l <tablaxaubacrlpca>  ! <tabla'>.<aviaboI'>)) 
:■  <auin9_aji> 
s“  <auin9jax'> 

:>  « 1 <cabXa><aut>accipca>  i <ubla>.<ayni»i'>  I DarAULT,<.aynbol'> 
!•  iva(iU>_a«>  Si,<*t>'th_ax>)) 

UAL  1 CfTBSER  1 t/SICAL  ! DOUBIE  1 AU>HA 
:■  . <lo>  1 <ld>)  $t.<ld>l 

:•  * I <valua_fn>  i <ib>  i <niaribac'>  1 <acrirq'>  i <atlth_ax'> 

1 <aubat<  in9_fn> 

:■  <inpuc_ai>  $|<vnpuc_al'>| 

:>  COiCitANr  ! NIWBES  1 SIOIGD  NUeSR  1 taOSO  1 SITING  ! vacrLn9> 


v«Eicn_w> 

I"* 


<.booiju> 
<t«aijiao 
^BOOi  _pclMCY> 


<C*i«Cton4i_M> 

<c«i«cian> 

<out9ut_«l> 


<tonACjic> 

<!(•'>  : 

(•cucnjn' 

uiu«£«t> 

<.«ji(on«nc'>  >’ 

<1«CMC>  > 

vOiqiO  : 

(waV4CMC'> 

< s^ac  I4i  ' 

(tottrin^iutc' 

vtO(MlC_CYf*'> 


<v«iu«_tn>  t <uie«3i_Cn>  l l 

<at»&«cx  1 <ia>  t <Ld><aubactlpts> 
ntwr«inpucjjtp'  SlCR  <input_qtp'l  ! <fcool_M*t' 
<fcooi^iaary^  >1  ! OR)  <booljpcia«iY'>| 

l<b004JiUK>) 

SYMac._Exiins  i<ufai«>.<tyitel>) 

1ML8_EHm  I<ubi«>l 
WXB_^EXISTS  «iilpue_CrM'>) 

PINO  «i.Tput_trt«>) 

<c«iacion«I_«x> 

<auin3_«»  <c*lAtlon> 

' I ■ l < l <•  l '■  1 <' 

a*b«i>  I iBDP  I ee_cp_rit2)  i loc*  i b®_op_tocoso) 
l ICCHIBITI  I Cs  ) I toot  1 CCUWN)  t<*Cleh_M>)  I 
<*ttlii3ju>  l<forMe_K>l 
PCRMRT  «tot»«t_typ«>)  I ■'  <f0CB»c_typ*' 

•$*<ncBbM' 

<l«ecac>  »ii<i«ct«rv  i <diqie>  i <«te«ch_«l'' 1 1 
»«id>  t «dwit>  $i(<dlqic>  1 <ia>]| 

_l<l«ctai>  { <dlqie>l 
*$<cfiAc«:c«c'> ' 

l>i-l  <dl<}ie>  ${<di<)ie>i  ). $<01410  t<wipon«nt'>] ] 

(*1-1  .oiiqiO  >i<di9iOJ  i<axpoMn01 
(B  1 0)  1*1-1  <di4io  $<01410 

AlBlClOlBlPlGiatIlJlKlLiniNlOl?lClR!SlTlUlVlV<lXiyiZ 

<illiai3l41$l«l7lbl9 

<l«ct«c>  1 <aiqio  1 <iOdCt«i_»Y«Coi'> 

any  onaiaccac  oenac  coan  <laccac'>  oc  <aiqit'>  includinq  blank 
any  lina  caac  tcon  cAa  fCP  kicnouc  a P in  coltatn  I 
any  laqai  POPTPAN  fccaac  cypa  at  par  inplasantation 
opcion.  bnouid  vnciuaa  at  laaac  A.B.f.l  fonMC  rypat. 
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*■  ****cioiEir  icmnij  iiiLiiijmoiPioiiiisiTioivimxi  Y!z 

<oigit>  ;•  Uili2i3l4lSi6i7ibl9 

<cO*t»ctat>  tm  <x«tt«c>  1 <di9it>  i <ap*cial  syBbol> 

any  charactar  ocliac  chan  <lateac>  or  «liglt>  including  blank 
<loctran_at«t>  «■  any  line  raad  Ccoa  cha  PCr  without  a ? in  coluan  1 

<toiaat.typa>  » any  iagal  rOklRAM  focaac  typo  aa  pac  iaplaaantacion 

option.  Should  includa  at  laast  A.E.f .1  Cocaat  typas. 
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6.4  SPECIFICATION  OF  LEXICAL  ANALYZERS 


LE<IC*L_AM4LY2E? .PROCEDURE: 

KITIALIZE  CURREMT  STATE  TO  ZERO; 

PREVIOUS. SYRaOL  * SYRSOL; 

IRlTIALIZc  SY'IBOL  TO  RJLL  STRIPS; 

00  FOREVER; 

IF  MEXT  CHARACTER  RESULTS  IV  LEGAL  TRAMSITIOH  FROM  CURRE.VT_STATE 
THEN  00; 

CATENATE  CHARACTER  ONTO  SYN30L; 

SET  CURRENT  STATE  TO  NEW  STATE; 

IF  CURRENT_STATE  « ZERO  THEN  RESET  SYN30L  TO  NULL; 

ENO; 

ELSE  IF  C'JRRENT_STAT£  IS  LESAL  FINAL  STATE 

THEN  RETURN  PR EV I OUS .SY N 30L^  SYNBOL,  SYMBOL  CLASS  NAME; 

ELSE  IF  NEXT  CHARACTER  IS  END  OF  FILE 
THEN  DO; 

SYN30L  » "EN0_0F_FILE“; 

SY130L.CLASS  * NULL; 

ENO; 

ELSE  DO; 

WRITE  ERROR  MESSAGE; 

IF  SYMBOL  IS  STILL  NULL  THEN  IGNORE  NEXT  CHARACTER 
RESTART  LEXICAL.ANALYZER.PROCEOURE  FROM  TOP; 

ENO; 

ENO; 

ENO  LEXICAL.ANALYZER  PROCEDURE; 


6.4.1,  FCF  Lexical  Analyzer 


FCF.LEXrCAL.AMALrZER  : 

EXECUTE  L6XICAL_ANALYZER_PR0CEDURE  AS  FOLLOWS: 

IMPUr  IS  TA<EW  FROM  FCF  FILE  LOCATION  IROICATEO  BY 

FCF_PAl?sr'(G^POlNTER; 

token  STRJCTU^E  is  that  INOICATEP  IN  FCF  LEXICAL  ANALYZER  STATE 

TRANSITIO'4  OIAGRAN; 

RETURNED  VALUES  ARE  CALLED  FC F_PREVIOUS_S YH0OL,  FCF  SYMBOL, 

AND  FCF^SYMBOL.CLASS; 

IF  FCF.SYMBOL.CLASS  IS  FORTRAN  THEN  ENTIRE  FORTRAN  STATEMENT 

IS  read  in  as  single  token; 

IF  TRACE  a "HIGH"  OR  "RIGHER’* 

THEN  IF  PRECOMPILER  OPERATION  IS  INHIBITED 

THEN  ADD  FC F_PR EV I OUS , SYMBOL  TO  TRACE  PRINT; 

ELSE  ADO  INTENSIFIED  FCF  PREVIOUS  SY'^BOL  TO  TRACE  PRINT 
END  FCF_LEXICAL_ANALYZER; 
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6.4.2.  Input  Lexical  Analyzer 


r'^3‘jr_L6xlCAL.A'IALrZER: 

EXECJTE-LEXlCAL-AMALtLZEa^PROCSOURE  AS  FOLLOWS: 

I'JPUT  IS  TA<EN  FROM  IMPUT  FILE  LOCATION  IMOICAFEO  3Y 

I.MPUT_PARSIMG_POINTER; 

TOKS.V  STRJCTURe  IS  THAT  I»DICATEo“l\'  INPUT  LEXICAL  ANALYZER  STATE 

TRANSITION  DIAGRAM; 

RETURNED  VALUES  ARE  CALLED  I NP  JT_PR  EV  lOUS  SYMBOL,  I'NPUT  SYM30L, 

AND  IN»UT_SYY30L_CLASS; 

IF  THIS  IS  POINT  OF  FARTHEST  PARSING'pROGHESS  THROUGH  CURRENT  NODE 
THEN  STORE  VALUE  OF  INPUT^PARSING  POINTER  AS  NEW  PROGRESS  MAR<PP 
End  INPUT^LEXICAL  ANALYZER; 
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STATE  TRANSITION  DIAGRAM 
INPUT  LEXICAL  ANALYZER 


6.4.3,  FORTRAN  Lexical  Analyzer 


F D ^ r ^ A M ^L£XLiLA.L_  A '4  ^L-Y Z £ R 1 

EXECUTE  lexical. ANALYZER.^RUCEDURE  AS  FOLLOWS: 

INPUT  IS  TAKEN  FRON  FCF  FILE  LOCATION  INOICATEO  3Y 

FCF.PARSING.POINTER; 

TOKEN  STRUCTURE  IS  TH At'inOI CATEO  IN  FORTRAN  LEXICAL  ANALYZER  STATE 

TRANSITION  DIASRA.N; 

IF  THIS  IS  A format  STATENENT  THEN  TOKEN  STRUCTURE  IS  THAT  INOICATEO 
IN  STATE  TRANSITION  DIAGRAM  FOR  FORHAT  STATEMENTS; 

RETURNED  VALUES  ARE  CALLED  FORTR  A.N.PR  EVIOUS.S  YNEOL^  FORTRAN  SYMBOL, 

AND  F0RTRAN_SYM?0L.CLASS; 

IF  FLTOPS  LENGTH  NOT  EO’JAL  TO  OFF  THEN^INCREMEN  T LENGTH 
3Y  ESTIMATE  OF  MEMORY  REQUIRED  FOR  CURRENT  TOKEN; 

END  FORTRAN.LEXICAL. ANALYZER; 
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Alphanumeric 


F (Number) 


m CtWft  BUT  f 


FORTRAN  FORNAT  STAItmNTS 


6.5  GLOSSARY 

ALPHA:  Default  entry  in  the  FLTOPS  symbol  table.  If  non-empty,  contains 
format  for  alphanumeric  conversion  of  data  returned  from  execute 
modules.  If  empty,  precompiler  uses  a default  conversion  procedure, 
the  exact  procedure  being  an  implementation  option.  Initial  value 
is  null . 

ARITH_OEPTHj:OUNTER:  Numeric  quantity  indicating  nest  level  at 

which  an  arithmetic  expression  is  being  evaluated.  Used  to 
control  switching  of  a flag  to  establish  PARAMETER_LOCATION 
values  when  initiated  by  an  EXECUTE  statement. 

ARITH_ELEMENT_FOUND:  “^rue/ false  flag  indicating  if  an  arithmetic  expres- 
sion consists  of  more  than  one  token  joined  by  a valid  arithmetic 
operator. 

ARITH_PAREN:  Counter  indicating  the  number  of  parentheses  encountered 

embedded  in  an  arithmetic  expression.  Used  with  PARENTHESISjCOUNT 
in  assuring  correct  parsing  of  boolean/arithmetic  expression  com- 
binations. 

ARITH_VALUE_STORED:  True/false  indicator  that  identifies  whether  or  not 
the  current  computed  value  in  an  arithmetic  expression  has  already 
been  pushed  onto  the  ARITHMETIC_STACK.  Used  to  insure  the  proper 
evaluation  of  boolean/arithmetic  expression  combinations. 

ARITHMETIC_STACK:  A precompiler  stack  containing  those  values  to  be  used 
in  evaluating  an  arithmetic  expression. 

ARRAY_P0SITI0N:  Number  representing  the  relative  location  in  a subscripted 
table  that  has  been  referenced.  The  number  is  computed  using  the 
subscripts  in  the  current  reference  and  the  dimensions  for  the 
table  that  appeared  in  the  last  applicable  DEFINE  statement. 

ARRAY_STACK:  A precompiler  stack  containing  the  values  of  each  subscript 
in  an  array  reference.  This  stack  is  used  with  the  dimension  in- 
formation from  the  DEFINE  statement  to  computer  ARRAY_P0SITI0N. 

BOOLEAN_TRUTH_STACK:  A precompiler  stack  containing  true/false  elements 
that  are  used  in  computing  boolean  expressions.  Also  used  in  tem- 
porarily saving  the  results  of  IF  conditional  tests. 

BROTHER_NODE_END : A true/false  indicator  which  indicates  if  all  subnodes 
in  the  input  file  at  a given  level  have  been  found. 
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COMPUTE_RELATIVE_POSITION:  True/false  flag  indicating  whether  or  not 
array  subscripts  should  be  used  in  computing  the  relative  value 
location  with  respect  to  predefined  dimension  values. 

COMPUTED_VALUE:  The  numeric  result  of  an  arithmetic  computation.  Used 
in  the  computation  of  arithmetic  expressions.  TEMPORARY_STRING 
contains  the  equivalent  string  representation  of  this  numeric  quan- 
tity. 

CONVERT_FLAG:  In/out  flag  indicating  whether  a given  quantity  is  to  be 

converted  to  internal  (IN)  format  or  to  external  (OUT)  string  format. 

CURRENT_TABLE_NAME : Name  of  the  last  symbol  table  reference  by  the  FCF. 

DEBUG:  Default  entry  in  the  FLTOPS  symbol  table.  On/off  switch  controlling 
the  execution/bypassing  of  STATUS  and  ASSERT  statements.  Initial 
value  is  off. 

DEFAULT_SYMBOL_TABLE:  The  table  name  with  which  non-subscripted  variable 
names  are  associated  in  arithmetic  expressions  and  within  the  SET 
statement.  Initially  set  to  FLTOPS. 

DEFAULT_TABLE_STACK;  Precompiler  stack  containing  the  names  of  all  tables 
currently  being  used  as  DEFAULT_SYMBOL  TABLES.  The  top  element  of 
the  stack  is  the  most  recently  defined  default  symbol  table. 

DEFINE_TABLE_NAME:  Table  name  appearing  in  a DEFINE  statement  which  is 
to  be  either  dimensioned  or  equivalenced. 

ERROR_MESSAGE_TABLE:  A predefined  table  containing  precompiler  error 
messages.  These  error  messages  can  be  referenced  by  their  order 
of  occurrence  within  the  table. 

ERROR_NUMBER:  A number  which  references  the  corresponding  entry  in  the 
ERROR_MESSAGE_TABLE. 

EQUIVALENCED_TABLE_NAME:  The  table  name  with  which  another  table  name  is 
equivalenced  in  the  DEFINE. . .AS. . . statement.  This  table  may  be 
non-empty  at  the  time  of  equivalence  or  it  may  be  previously 
equivalenced. 
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EXECUTE_DATA_AREA:  The  area  shared  by  both  an  execute  module  and  the 
precompiler  in  which  data  needed  and/or  computed  by  the  execute 
module  Is  stored. 

EXECUTEJ)ATA_AREA_POINTER:  A pointer  indicating  the  location  in  the 
EXECUTE_OATA_AREA  where  the  next  data  value  is  to  be  stored  or 
retrieved. 

EXECUTE_ENVIRONMENT_TABLE:  An  internal  table  maintained  for  every  routine 
that  appears  in  a PARAMETERS  statement.  For  every  parameter  in  the 
argument  list  a table  entry  is  saved  for  PARAMETER_CLASS t PARAMETER_ 
SIZE  AND  PARAMETER_LOCATION  information. 

EXECUTE_ROUTINE_NAME:  A coded  identifier  consisting  of  a $ catenated 
with  the  routine  name  appearing  in  a PARAMETERS  statement.  It 
refers  both  to  an  EXECUTE_ENVIRONMENT_TABLE  and  without  the  $ to 
the  execute  module. 

FATAL_ERROR:  Any  error  from  which  any  means  of  error  recovery  is  impossible. 
Except  for  output  of  status  information,  all  precompiler  functions 
cease. 

FCF_LEXICAL_ANALYZER:  That  portion  of  the  precompiler  which  analyzes  the 
FLTOPS  configuration  file  input  stream  and  identifies  the  individual 
tokens. 

FCF_PARSING__POINTER:  A pointer  which  identifies  the  location  in  the  FCF 
at  which  token  recognition  will  resume  on  the  next  invocation  of 
the  FCF_LEXICAL_ANALYZER. 

FCF_PARSING_TRUE_FALSE_INDICATOR:  Master  precompiler  control  flag.  Set  to 
true,  if  the  current  syntactic  element  is  satisfied.  Thus,  it  is 
set  to  true  if  the  token  in  FCF_SYMBOL  matches  the  current  syntactic 
element,  or  it  can  also  be  set  directly  by  various  functional 
primitives.  Once  set  to  false,  the  remaining  mandatory  syntactic 
and  associated  semantic  constructs  in  a given  rule  are  not  processed. 

FCF_PREVIOUS_SYMBOL:  The  last  token  from  the  FCF  successfully  recognized 
as  a syntactic  element  in  the  granmar.  Often  references  by  the 
shorthand  notation  * (asterisk). 
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FCF_SYMBOL:  The  token  just  recognized  by  the  FCF_LEXICAL_ANALYZER;  the 
next  token  to  be  parsed  by  the  precompiler. 

FCF_SYMBOL_CLASS : The  class  of  the  token  in  FCF_SYMBOL.  It  may  be  a number, 
an  identifier,  etc. 

FINISH_FLA6:  True/false  flag  whether  or  not  an  entire  input  tree  specifi- 
cation has  been  parsed.  Also  used  to  indicate  whether  or  not  all 
elements  in  the  catenated  form  of  the  INPUT  command  have  been  pursed. 

FLTOPS:  A predefined  symbol  table  available  for  all  FCF  users.  It  con- 
tains several  predefined  symbols  that  can  be  used  to  control  the 
operation  of  the  precompiler. 

FLTOPS  FUNCTION:  A flag  indicating  which  of  four  functional  modes  the  pre- 
compiler is  in: SCAN,  SYNTAX,  TEST  or  FULL.  In  SCAN  the  precompiler 
is  conditionally  bypassing  a portion  of  the  FCF  and  does  only  syntax 
checking;  in  SYNTAX,  the  precompiler  will  only  do  syntax  checking, 
once  set  to  SYNTAX  it  cannot  be  set  to  anything  else.  In  TEST, 
the  precompiler  is  fully  operational  except  no  FORTRAN  output  is 
generated.  In  FULL,  all  precompiler  functions  including  FORTRAN 
output  are  operational.  Except  for  SCAN,  these  precompiler  functions 
are  controllable  by  the  user  through  the  symbol  FUNCTION  in  the  FLTOPS 
symbol  table. 

FORTRAN_LEXICAL_ANALYZER:  That  portion  of  the  precompiler  which  analyzes 
FORTRAN  statements  to  identify  the  individual  tokens. 

FORTRAN_PARSING_POINTER:  A pointer  which  identifies  the  location  within  a 
FORTRAN  statement  at  which  token  recognition  will  resume  on  the  next 
invocation  of  the  FORTRAN_LEXICAL_ANALYZER. 

FORTRAN_PREVIOUS_SYMBOL:  The  last  token  recognized  in  the  current  FORTRAN 
statement  as  returned  by  the  lexical  analyzer. 

FORTRAN-SYMBOL:  The  token  just  recognized  by  the  FORTRAN_LEXICAL_ANALYZER. 

FORTRAN_SYMBOL_CLASS:  The  class  of  the  token  in  F0RTRAN_SYMB0L .'  Could 
be  number,  identifier,  etc. 

FOUND_FLAG:  True/false  flag  indicating  whether  or  not  a specific  node  of 
an  input  tree  actually  was  found  in  the  input  file. 
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HEADING:  A string  literal  that  Is  written  out  whenever  the  STATUS  conmand 
1e  executed. 

INPUTJLEXICAL_ANALYZER:  That  portion  of  the  precompiler  which  analyzes  the 
Input  data  stream  to  Identify  Individual  tokens. 

INPUT_PARSING_POINTER:  A pointer  which  Identifies  the  location  In  the  In- 
put file  at  which  token  recognition  will  resume  on  the  next  Invoca- 
tion of  the  Input  lexical  analyzer. 

INPUT_POINTER  STACK:  A precompiler  stack  containing  values  of  the  INPUT_ 
PARSING_POINTER.  This  Is  the  only  precompiler  stack  directly 
accessible  to  the  FCF  builder  through  use  of  the  SAVE_POINTER  and 
REST0RE_P0 INTER  conmands. 

INPUT_PREVIOUS_SYMBOL:  The  last  token  recognized  as  Input  by  the  FCF  as 
returned  by  the  INPUTJ.EXICAL_ANALYZER. 

INPUT_SYMBOL:  The  token  just  recognized  by  the  INPUTJLEXICAL_ANALYZER. 

INPUT_SYMBOL_CLASS:  The  class  of  the  token  in  INPUTJSYMBOL.  Could  be 
Identifier,  number,  etc. 

INTEGER:  Default  entry  In  the  FLTOPS  symbol  table.  If  non-empty,  contains 
format  for  conversion  of  Integer  values  returned  from  execute 
modules.  If  empty,  precompiler  uses  a default  conversion  pro- 
cedure. The  exact  procedure  Is  an  Implementation  option.  Initial 
value  Is  null . 

KEY_WORD_TABLE:  An  Internal  table  containing  key  words  used  In  error  re- 
covery. Once  a severe  error  occurs,  the  FCF  Is  scanned  for  a key 
word.  Once  a key  word  Is  found,  FCF  parsing  resumes  at  that  location. 

LBLNUM:  Default  entry  In  the  FLTOPS  symbol  table.  Used  as  the  base  value 
In  generating  statement  lables.  Initial  value  Is  99000. 

LENGTH:  Default  entry  In  the  FLTOPS  symbol  table.  If  set  to  a number 
greater  than  or  equal  to  zero,  LENGTH  Is  a counter  Incremented  by 
the  FORTRAN J.EXICAL_ANALYZER  by  fixed  amount  for  each  token  required 
Initial  value  Is  off. 


LOCATION_INFORMATION:  A storage  location  containing  sufficient  information  | 

to  indicate  to  the  precompiler  when  scanning  of  the  FCF,  caused  by  a 
conditional  test,  should  cease  and  regular  processing  (even  if  simply 
syntax  checking)  should  resume. 

LOGICAL:  Default  entry  in  the  FLTOPS  symbol  table.  If  non-empty,  contains 
the  format  for  conversion  of  logical  data  returned  from  execute 
modules.  If  empty,  the  precompiler  uses  a default  conversion  procedure. 

The  exact  procedure  is  an  implementation  option.  Initial  value  is  null. 

MESSAGE:  String  literal  containing  the  message  being  output  via  the  MESSAGE 
statement. 

NOTE:  A message  of  possible  documentary  or  informative  interest.  It  has 
no  effect  on  precompiler  functions. 

NOTES:  Default  entry  in  the  FLTOPS  symbol  table.  Used  as  an  on/off  switch 
indicating  whether  or  not  note  level  messages  are  to  be  written  out  or 
suppressed  respectively. 

N0TE_C0UNT:  A number  indicating  how  many  times  a note  level  message  has  been 
issued. 

OPERATION_TRUE_FALSE_INDICATOR:  True/false  indicator  identifying  the  success 
or  failure  of  basic  precompiler  operations. 

0PERAT0R_STACK:  A precompiler  stack  containing  those  arithmetic  operators 
to  be  used  in  evaluating  an  arithmetic  expression. 

i 

OUTPUT:  Default  entry  in  the  FLTOPS  symbol  table.  Switch  controlling  the 
format  of  the  customized  code  produced.  Initially  set  to  FORTRAN 
but  also  can  be  set  to  DATA  in  which  no  special  card  image  format 
is  produced.  j 

■I 

OUTPUT_BUFFER:  Collection  area  where  a FORTRAN  statement  is  stored  until  j 

a STATEMENT_TERMINATOR  is  encountered.  ‘ ^ 

t 

OUTPUT_COMMENT_CARD:  True/false  indicator  set  to  true  whenever  a comment  . 

card  is  output  via  the  OUTPUT  command.  Upon  receipt  of  a statement  ^ 

terminator  it  is  reset  to  false.  i 

PARAMETER_CLASS : The  type  of  value,  i.e.,  REAL,  INTEGER,  etc.,  to  be  - |] 

passed  to  an  execute  module  through  the  EXECUTE_DATE_AREA.  | 
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PARAMETER_COUNT : A number  identifying  which  parameter  in  an  argument  list 
is  currently  being  processed. 

PARAMETER_LOCATION:  The  symbol  table  location  where  the  current  parameter 
being  processed  can  be  found. 

PARAMETER_SIZE:  The  number  of  values  starting  at  the  location  identified 
by  PARAMETER_LOCATION  to  be  transferred  into  or  restored  *rom  the 
EXECUTE_DATA_AREA. 

PARENTHESIS_COUNT:  A number  used  to  keep  track  of  parenthesis  used  in  a 
boolean/arithmetic  expression  combination. 

PASS1_0UTPUT_FILE:  Temporary  file  where  precompiler  non-printing  output 
is  kept  while  the  precompiler  interprets  the  FCF. 

PASS2_0UTPUT_FILE:  FORTRAN  output  Suitable  for  input  to  a compiler. 

Generated  as  the  final  product  of  a precompiler  run. 

PASS1_PASS2_SWITCH:  Internal  precompiler  switch  indicating  whether  or  not 
this  is  the  first  or  second  pass.  On  Pass  1 the  FCF  is  interprested 
and  the  PASS1_0UTPUT_FILE  created.  On  Pass  2»  the  PASSIJDUTPUTJILE 
is  read  and  the  PASS2_0UTPUT_FILE  ts  written. 

PASS1_TABLE:  Symbol  table  used  by  the  precompiler  on  Pass  1 substitution. 

Any  FORTRAN  token  matching  a symbol  entry  during  Pass  1 is  replaced 
by  the  corresponding  table  value. 

PASS2_TABLE:  Symbol  table  used  by  the  precompiler  on  Pass  2 substitution. 

Any  FORTRAN  token  matching  a symbol  entry  during  Pass  2 is  replaced 

by  the  corresponding  table  value.  i 

PROCEDURE_NAME_STACK:  Precompiler  stack  containing  all  FCF  rules  (procedures)  ; 

that  are  currently  invoked. 

REAL:  Default  entry  in  the  FLTOPS  symbol  table.  If  non-empty,  contains 
a format  for  the  conversion  of  real  data  returned  from  an  execute 
module.  If  empty,  the  precompiler  uses  a default  conversion  pro- 
cedure. The  exact  procedure  is  an  implementation  option.  Initial  '|| 

value  is  null . '] 
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RECOVERY_POINT_STACK:  Precompiler  stack  containing  FCF_PARSING_POIflTER 
values.  Used  to  Identify  that  location  to  which  control  will  be 
transferred  upon  completion  of  a loop  or  Invoke  construct. 

RELATIONAL_EXPRESSION:  True/false  flag  Indicating  whether  or  not  the  current 
element  In  a boolean  expression  will  take  the  form  of  a relational 
expression. 

RELAX ION_TYPE_FLAG:  A flag  indicating  which  relation  type  (e.g. 

etc.)  to  use  in  evaluating  the  truth  or  falsity  of  a relational 
expression. 

SAVED_POINTER_STACK:  Precompiler  stack  containing  values  of  the  SYMB0L_ 
TABLE_P0 INTER.  Used  to  save  the  location  where  a specified  value 
is  to  be  entered/ retrieved. 

SAVED_VAlUE:  Location  containing  the  first  of  two  values  to  be  compared 
in  a relational  expression. 

SEVERE_ERROR:  An  error  such  that  the  precompiler  cannot  perform  its 
functions  satisfactorily  on  the  data  received. 

SEVERE_ERROR_COUNT:  A number  indicating  how  many  times  a SEVERE_ERROR 
has  occurred.  Once  a severe  error  occurs  in  the  FCF,  all  precom- 
piler functions  except  syntax  checking  are  shut  down. 

STACK_SIZE:  A value  indicating  the  number  of  values  to  be  popped  from 
ARRAY_STACK  and  used  in  subscript  computations. 

START_P0S:  Numeric  quantity  indicating  the  character  position  at  which  a 
substring  becins.  Used  bnth  tr  the  INPEX  and  SUBSTRING  statements. 

STATEMENT_TERMINATOR:  A unique  character  or  group  of  characters  which 
indicate  when  the  OUTPUT_BUFFER  is  to  be  written. 

STATS:  Default  entry  in  the  FLTOPS  symbol  table.  Used  as  an  on/off  switch 
indicating  whether  or  not  statistical  information  is  to  be  computed 
and  written  out.  Initial  value  is  off. 

STRING1 : Temporary  string  variable  used  to  store  substring  to  be  replaced 
in  a REPLACE  statement. 
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STRING2:  Temporary  string  variable  used  to  store  the  string  to  be  inserted 
in  another  string  with  the  REPLACE  statement. 

STRING_IN:  Temporary  string  variable  containing  the  string  upon  which  l^ie 
SUBSTRING  function  will  operate. 

STRING_LENGTH:  Variable  indicating  both  the  length  that  a substring  is  to 
be  in  the  SUBSTRING  function  and  the  length  of  an  actual  string  in 
the  LENGTH  function. 

SUBSCRIPT_COUNTER_STACK:  A precompiler  stack  containing  values,  each 

referencing  the  number  of  subscripts  in  an  array  specification.  A 
stack  is  necessary  since  array  references  can  be  nested,  e.g., 
A(7,B(3,2)). 

SYMB0L_TABLE_P0 INTER:  An  internal  pointer  indicating  the  symbol  table 
location  most  recently  referenced. 

TABLE_HEADER:  General  purpose  location  for  each  table.  May  contain  a 
variety  of  information  useful  to  managing  table  entries.  Always 
contains  dimension  information  for  those  tables  appearing  in  a 
DEFINE  statement.  Subscripts  are  assumed  stored  in  the  order  of 
their  appearance. 

TEMPORARY_STRING:  All  purpose  string  variable  --  often  referred  to  by  the 
shorthand  notation  **  (double  asterisk). 

TRACE:  Default  entry  in  the  FLTOPS  symbol  table.  Used  as  an  on/off  switch 
controlling  the  generation  of  trace  information.  Initial  value  is 
off. 

VALUE_L0CATI0N:  The  symbol  table  location  from  which  the  last  table  value 
was  retrieved. 

WARNING:  An  error  which  most  likely  is  an  unintended  user  mistake,  but 
which  does  not  confuse  the  semantic  intent  of  the  statement. 

WARNIN6_CCUNT:  A number  indicating  how  many  times  a WARNING  message  has 
been  issued. 


XREF:  Default  entry  in  the  FLTOPS  symbol  table.  Used  as  an  on/off  switch 
indicating  whether  or  not  a cross  reference  map  of  the  FCF  should  be 
generated.  Initial  value  is  off. 


7.0  IMPLEMENTATION  ISSUES 
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Inherent  in  any  design  are  areas  which  must  be  paid  special  atten- 
tion when  implementation  begins.  In  the  FLTOPS  precompiler  design  there 
are  several  of  these  special  areas.  The  method  by  which  symbol  table  storage 
is  accessed  and  the  means  by  which  the  execute  command  is  implemented  can 
both  have  a treniendous  impact  on  the  efficiency  of  the  precompiler.  De- 
pending on  the  actual  file  structure  adopted  for  input  and  FCF  data,  file 
preprocessing  may  also  be  an  important  consideration  for  the  implementor. 

Although  there  can  be  little  actually  done  about  the  system  and  language 
which  the  implementor  uses,  these,  too,  can  have  an  important  effect  on  the 
implementation  effort.  Although  incomplete  in  many  ways,  the  following 
sections  provide  some  considerations  for  the  implementor  in  each  of  the 
aforementioned  areas. 

7.1  SYMBOL  TABLE  IMPLEMENTATION  OPTIONS 

The  symbol  table  operations  as  specified  in  the  FLTOPS  design  are 
not  assumed  to  be  ordered  or  partitioned  in  any  particular  way  for  purposes 
of  execution  efficiency,  nor  is  any  particular  (non-sequential ) search  method 
assumed.  However,  the  implementor  should  keep  in  mind  that  data  storage/ 
retrieval  times  are  one  of  the  primary  factors  in  precompiler  run  time. 

As  a result,  the  implementor  is  expected  to  select  a highly  efficient  ap- 
proach to  symbol  table  operations,  based  upon  considerations  of  design, 
usage  and  the  implementation  environment.  For  example,  table  and  symbol 
entries  might  actually  be  structured  in  the  form  of  binary  trees  for  ef- 
ficient search  (see  Wegner,  1968,  p.  168).  Table  names,  symbol  names, 
and  values  are  not  restricted  in  length,  as  such  an  efficient  means  of 
allocating  new  and  releasing  old  storage  is  a must.  One  of  several 
approaches  the  implementor  might  take  is  the  "buddy  system"  (see  Knuth, 

1968).  'h 
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Since  there  are  two  distinct  methods  of  referenc1n9  symbol  table 
storage  as  outlined  in  the  design  specification,  the  implementor  might  want 
to  specify  different  mechanisms  for  accessing  array  tables  than  for  regular 
symbol  tables.  This  may  not  be  necessary,  however,  especially  if  sparse 
matrix  storage/retrieval  techniques  prove  to  be  applicable. 

Obviously,  there  are  many  more  options  available  to  the  Implementor 
than  listed  here.  The  key  concept,  however,  is  to  implement  symbol  table 
access  in  a highly  efficient  manner.  Care  taken  in  this  area  could  result 
in  a highly  efficient  precompiler. 


7.2  ALTERNATIVES  FOR  IMPLEMENTING  THE  "EXECUTE"  STATEMENT 

The  FLTOPS  precompiler  design  provides  the  capability  of  interfacing 
with  already  compiled  program  modules.  How  this  interface  actually  occurs 
can  be  extremely  important  in  determining  precompiler  efficiency  and  the 
time  and  effort  required  for  actual  implementation.  Although  other  schemes 
might  be  found  in  actual  implementation,  three  procedures  have  been  iden- 
tified to  date.  All  can  utilize  the  design  methodology  in  which  values  are 
shared  between  programs  In  a known  common  area.  This  common  area  may  be 
actual  memory  locations  or  an  external  medium  such  as  a disk  file. 

The  first  workable  procedure  is  through  use  of  the  system  job  control 
languaoc.  Essentially,  the  precompiler  oi’^d  execute  routine  would  be  sepa- 
rate and  distinct  jobs.  When  the  precompiler  encounters  the  EXECUTE  com- 
mand, it  suspends  processing  after  loading  the  crmmon  area  with  the  desig- 
nated values,  and  enough  information  is  saved  so  that  the  precompiler  can 
be  restarted  properly.  The  precompiler  sets  a switch  which  can  be  accessed 
via  the  job  control  stream.  The  switch  setting  indicates  which  execute 
routine  should  be  loaded  and  executed.  After  completion  of  this  routine, 
the  precompiler  is  restarted  at  the  appropriate  program  step  and  the  values 
computed  by  the  execute  routine  are  entered  into  the  associated  symbol  table 
locations. 

Notice  that  there  are  several  requirements  for  this  procedure  to  work. 
The  first  requirement  is  a high  level  job  control  language  that  has  the 
capability  to  repeatedly,  as  well  as  conditionally  execute  job  control  state- 
ments. Additionally,  the  capability  to  set  a JCL  accessible  switch  from 
inside  a program  is  essential.  Although  it  appears  that  there  are  various 
JCL's  in  existence  that  could  do  this  (e.g.,  some  versions  of  KRONOS  or 
NOS-BE  for  CDC  systems),  it  is  not  a universal  capability  that  most  computer 
vendors  supply  As  such,  the  procedure  might  have  to  be  entirely  redone, 
instead  of  simply  being  modified,  if  computer  systems  were  changed.  In 
addition,  the  job  control  decks  needed  for  any  specified  FCF  might  be  very 
long  and  complicated  to  construct.  It  has  not  as  yet  been  determined  that 
the  operating  system  currently  installed  on  AFFTC  computers  can  perform  all 
necessary  JCL  variations. 
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An  alternative  procedure  is  to  cause  the  system  to  load  the  execute 
routine  into  memory  either  at  an  absolute  location  or  as  part  of  the  pre- 
compiler. Each  time  a new  routine  is  to  be  executed,  it  would  replace 
the  one  currently  in  memory.  A simple  way  to  think  of  this  would  be  as  an 
emulation  of  an  overlay  procedure.  Once  loaded,  the  execute  module  would 
process  the  data  and  transfer  control  back  to  the  precompiler. 

Notice  that  the  requirements  for  using  this  kind  of  system  are  simply 
a process  to  load  the  correct  module  into  the  designated  location  in  memory 
and  a procedure  to  transfer  control  properly.  Although  few  in  number,  the 
requirements  could  be  much  harder  to  implement.  To  actually  load  a module 
into  core  is  a complicated  process.  It  could  be  as  simply  as  calling  the 
system  load  routine  from  the  precompiler  or  could  be  as  difficult  as  writing 
a specialized  load  routine.  In  either  case,  some  expert  knowledge  of  the 
operating  system,  compiler  table  structures,  and  loading  procedures  is 
necessary.  Even  more  than  with  the  JCL  procedure  mentioned  earlier,  this 
procedure  is  very  dependent  upon  the  system  used.  However,  once  working, 
this  could  be  very  efficient. 

A third  alternative  combines  simplicity  of  operation  with  trans- 
portability. In  this  procedure,  all  execute  routines  for  a particular  FCF 
are  linked  together  with  the  precompiler  in  an  overlay  structure.  Each 
execute  routine  would  be  overlayed  at  the  same  level.  A special  subroutine 
would  be  written  to  control  the  calling  of  the  separate  execute  routine 
overlays.  The  necessary  data  (e.g.,  the  overlay  file  name  and  overlay  level 
numbers)  controlling  tite  overlay  calling  would  be  a part  of  this  subroutine 
would  be  written  to  control  the  calling  of  the  separate  execute  routine 
overlays.  The  necessary  data  (e.g.,  the  overlay  file  name  and  overlay  level 
numbers)  controlling  the  overlay  calling  would  be  a part  of  this  subroutine. 
It  is  expected  that  a special  subroutine  would  have  to  be  written  for  each 
separate  FCF.  Each  time  a new  execute  module  were  added,  a new  overlay 
with  the  precompiler  would  have  to  be  built.  Although  every  system  has  its 
own  overlay  structure,  this  concept  is  sufficiently  general  to  accommodate 
them  all.  A particularly  nice  feature  of  CDC  overlay  structures  is  the 
capability  to  save  separate  overlay  levels  on  independent  files  if  desired. 
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In  this  application,  each  separate  FCF  could  have  its  own  execute  library 
that  could  be  overlayed  with  a single  copy  of  the  precompiler  overlay. 


Although  the  details  are  not  completely  worked  out,  the  third 
procedure  seems  the  most  favorable  implemention  mechanism  at  this  time. 

It,  too,  is  somewhat  system  specific,  but  is  easier  to  implement  and  use 
than  either  of  the  other  two.  The  implementor  in  any  case  should  endeavor 
to  provide  a procedure  that  minimizes  the  effect  of  possible  system  changes 
and  yet  remains  easy  to  use,  and,  if  possible,  to  implement. 


7.3  FILE  PREPROCESSING 


Depending  on  the  file  structure  adopted  at  implementation  time,  it 
might  be  desirable  to  preprocess  the  input  and  FCF  files  to  make  direct 
access  possible  to  the  various  segments  of  each  file.  Preprocessing  of  the 
input  file  has  already  been  flagged  as  a part  of  the  design.  This  is  so 
because  of  the  hierarchic  nature  of  the  FCF  inputs  and  the  nature  of  various 
input  commands. 

Not  actually  mentioned  in  the  design,  but  clearly  an  issue  for  the 
implementor.  Is  preprocessing  of  the  FCF  and  the  FCF  users  library  so  that 
direct  access  to  each  rule  is  possible.  Direct  access  techniques  would  enable 
the  FCF  to  transfer  parsing  control  among  routines  without  seriously  de- 
grading precompiler  execution  times.  If  forced  to  scan  the  FCF  or  users 
library  sequentially  in  search  of  the  rule  to  receive  parsing  control,  a 
severe  increase  in  I/O  and  processing  times  could  be  expected  for  even 
moderately  large  FCF  files.  As  such,  the  FCF  user  would  be  forced  to  place 
a premium  on  file  organization.  With  the  increased  file  management  support 
offered  by  most  major  computer  vendors,  it  is  entirely  possible  that  no 
specialized  software  need  be  written  to  accomplish  direct  access  to  each 
FCF  rule.  Instead,  the  FCF  could  be  "managed"  by  system  software.  Before 
using  any  such  standard  package,  however,  the  implementor  should  weigh 
the  impact  of  its  use  against  possible  effects  caused  by  future  system  changes. 
In  any  case,  the  implementor  should  be  aware  of  the  desirability  of  direct 
access  in  both  the  input  and  FCF  files  and  provide  a scheme  that  accomplishes 
this  aim  without  severely  restricting  precompiler  portability. 
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7.4  LANGUAGE  AND  SYSTEM  CONSIDERATIONS 


The  language  and  system  that  the  FLTOPS  design  Is  Initially  Implemented 
on  will  have  a direct  affect  on  some  aspects  of  the  implementation.  FORTRAN 
is  the  designated  target  language  for  FLTOPS  implementation.  Because  of 
some  symbol  table  operations  and  the  ability  to  use  arithmetic  expressions, 
string  manipulation  and  data  conversion  capabilities  are  required  aspects 
of  the  design  implementation.  ANSI  standard  FORTRAN  does  not  define  as  a 
standard  language  element  the  capability  to  do  either  of  the  above.  As  a 
result,  the  way  each  can  be  done  varies  with  the  FORTRAN  provided  by  the 
vendor.  Most  vendors  provide  intrinsic  functions  callable  from  FORTRAN 
which  can  be  used  directly,  or  in  some  combination,  to  provide  the  above 
functions.  For  example,  ENCODE  and  DECODE  statements  can  be  used  in  some 
FORTRAN  compilers  for  data  conversions.  Such  statements  are  not  available 
with,  among  others,  the  IBM  FORTRAN  H compiler.  Functions  which  allow 
masking,  shifting  and  boolean  operations  are  also  supplied  with  many  compilers. 
However,  the  form  of  these  functions  is  very  rarely  compatible.  As  a result, 
the  implementor  should  make  judicious  use  of  any  compiler  specific  functions. 
When  used,  they  should  be  adequately  documented  and  structured  so  as  to  make 
future  changes  relatively  straightforward. 

The  operating  system  on  which  the  implementation  is  done  will  un- 
avoidably affect  some  aspects  of  the  implementation.  Although  the  design 
requires  no  system  peculiarities,  the  implementor  is  cautioned  that  in 
instances  where  system  peculiarities  exist  that  would  enhance  implementation 
efforts,  use  of  these  alternatives  should  occur  only  after  properly  weigh- 
ing the  downstream  effect  of  future,  possibly  adverse,  system  changes. 

For  example,  if  the  decision  were  made  to  use  the  specialized  features  of 
a JCL  to  implement  EXECUTE  commands  (see  Section  7.2),  a change  to  a new 
computer  system  without  that  feature  would  result  in  a demand  for  a new 
implementation  procedure.  Thus,  the  EXECUTE  comnand  would  need  to  be  re- 
implemented. Some  small  changes  are  to  be  expected  when  installing  any 
large  program  on  a different  system.  However,  the  implementor  can  cause  the 
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number  of  changes  to  be  kept  to  a minimum  by  paying  close  attention  to  all 
implementation  alternatives  available  and  choosing  Judiciously. 


8.0  REFERENCES 


Knuth,  0.  E.  The  Art  of  Computer  Programming.  Vol.  1.  Addison  Wesley 
Publishing  Company,  Inc.  . Reading,  Nassacnusetts,  1968. 

Naur,  P.  (Ed.)  Report  on  the  Algorithmic  Language  AL60L60.  Communi- 
cations of  the  ACM.  1960.  3,  299-314. 

Wegner,  P.  Programming  Languages,  Informap'on  Structures  and  Machine 
Qrqanizationr  McGraw-Hi il . New  York.  1965. 


8-1 


APPENDIX  A 


FLTOPS  DESIGN  VALIDATION  STUDY 

A. I INTRODUCTION 

The  FLTOPS  design  as  originally  conceived  provided  a formal,  complete 
and  rigorous  specification  of  the  actual  system  proposed  for  implementation. 
However,  the  uniqueness  of  the  concept  combined  with  the  necessary  complexity 
of  the  design  specification  made  it  extremely  difficult  to  verify  by  conven- 
tional means  its  logical  correctness  and  completeness.  Yet,  it  was  determined 
that  just  such  a verification  and  validation  was  needed  to  prove  the  soundness 
and  usefulness  of  the  concept.  This  need,  combined  with  the  existence  of  some 
unique  software  previously  written  by  SAI  staff  members,  provided  the  incentive 
and  mechanism  for  this  effort.  The  validation  effort  took  the  form  of  an 
executing  functional  prototype  which  served  to: 

. validate  that  the  functional  design  specified  was  an  integrated 
and  complete  design; 

. provide  a means  for  AFFTC  to  evaluate  the  utility  and  potential 
benefits  of  the  FLTOPS  design  in  a set  of  realistic  AFFTC 
scenarios; 

. provide  a means  for  demonstrating  and  communicating  the  FLTOPS 
concept  that  was  less  sterile  than  formal  specification  documents 
or  technical  briefings; 

. provide  a means  for  transferring  technical  familiarity  from  the 
designers  to  the  potential  users  of  FLTOPS; 

. provide  a means  for  discovering  potential  implementation  cost 
drivers  before  implementation  commitments  are  made; 

. develop  the  insights  necessary  to  estimate  the  scope  of  making 
a transition  from  existing  source  code  libraries  to  quasi-source 
code  libraries. 

Under  certain  circumstances  the  costs  of  such  a functional  prototype 
would  be  prohibitively  high.  However,  the  requirements  of  FLTOPS  and  the 
choice  of  design  specification  mechanisms  were  compatible  with  the  capabilities 
of  the  Translater  Writing  System,  developed  for  NASA  by  members  of  the  SAI 
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staff.  T‘’is  combination  provided  a unique  opportunity  for  the  Air  Force  to 
set  a hands-on  capability  and  served  to  provide  a continuing  medium  for  teach- 
ing and  evaluation  before  actual  FLTOPS  implementation  ts  begun, 

Although  the  end  product  of  this  validation  effort  is  a functional 
prototype  which  actually  performs  the  FLTOPS  operations,  it  cannot  perfonn 
efficiently  or  realistically  enough  in  this  form  to  be  considered  ao  implemented 
FLTOPS.  The  "quick  and  dirty"  approach  served  the  purpose  of  validating  the 
design,  but  cannot  satisfy  actual  Implementation  requirements  where  memory 
utilization  and  processing  efficiency  are  key  requirements. 

The  validation  effort  consisted  of  three  basic  tasks: 

. develop  a set  of  executable  procedures  that  perform  the  FLTOPS 
functions  as  described  by  the  functional  primitives  presented  In 
section  6. 

. adapt  the  augmented  gramnar  presented  in  section  6 into  a form 
compatible  with  the  Translator  Writing  System.  Execute  the  TWS 
with  this  adapted  grammar  as  input  to  produce  an  executable  pro- 
gram that  serves  as  the  FLTOPS  statement  processor. 

. combine  the  first  two  activities  into  an  integrated  functional 
FLTOPS  that  is  capable  of  processing  actual  FCF.  Included  in 
this  task  was  the  development  of  several  test  FCF's  that  would  test 
the  logical  and  functional  adequacy  of  both  the  FLTOPS  primitives 
and  a.ugme-'ted  gvavnar  specif  catu'rij. 

A discussion  of  these  tasks  is  provided  below.  In  addition,  the  con- 
cluding section  in  this  appendix  details  the  major  changes  in  the  design 
that  resulted  from  this  effort. 
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A-2  DEVELOPMENT  OF  EXECUTABLE  CODE  THAT  PERFORMS  THE  FLTOPS  FUNCTIONS 


All  code  development  for  FLTOPS  was  done  in  the  ?L/1  prograrming 
language.  This  was  so  for  two  basic  reasons: 

1)  the  POL  used  in  the  specification  mechanisms  is  similar  in 
many  respects  to  PL/1  code.  As  a result,  transformation  of 
the  PDL  was  much  simplified. 

2)  the  output  of  the  TWS  is  PL/1  code.  Since  the  statement  pro- 
cessor was  generated  in  PL/1  code,  efficiency  and  compatability 
demanded  the  primitives  be  similarly  coded. 

Each  primitive  was  coded  as  a separate  PL/1  procedure  and  was  tested  for 
functional  adequacy  in  its  performance  before  being  integrated  with  the  other 
primitives  into  the  functional  prototype.  Such  off  line  testing  eliminated 
many  deficiencies  in  the  program  at  the  outset. 

Although  all  primitives  were  coded,  some  simplifying  assumptions  were 
made  with  respect  to  symbol  table  access,  the  execute  related  primitives,  as 
well  as  the  input/FCF  file  structures  so  as  to  hasten  the  completion  of  a 
working  emulator.  This  "quick  and  dirty"  approach  was  justified  because 
of  the  goal  of  the  validation  effort,  i.e.  to  test  the  FLTOPS  design  for 
deficiencies,  not  provide  an  implemented  system.  As  a result;  sequential 
searches  are  made  through  each  table  for  the  various  entries;  array  tables 
are  handled  exactly  as  are  symbol  tables;  table  entries  are  limited  to  50 
characters;  the  use  of  comment  cards  in  input  and  FCF  files  are  mildly 
restricted;  only  medium  size  FCF  (<  2000  lines)  files  are  permitted; 

>1 

execute  modules  can  be  run,  but  must  be  in  PL/1  and  linked  at  the  same  time  || 

, i 

as  the  rest  of  the  emulator;  there  can  be  no  libraries  of  FCF  code  nor  can  ‘ 

FCF  rules  appear  in  the  input  file. 

'll 

t; 

Although  these  and  other  deficiences  exist  that  would  detract  from  ij 

an  implemented  system,  the  emulator  does  functionally  perform  as  prescribed  i 

by  the  design  for  those  input/FCF  files  that  conform  to  this  simplified  foimiat.  i 
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Very  few  changes  were  made  in  the  functional  primitives  from  that  given 
in  the  previous  draft  of  this  document.  Several  new  primitives  were  added, 
however,  to  perform  the  functions  required  by  new  capabilities  added  during  the 
validation  study. 

A-3  DEVELOPMENT  OF  THE  STATEMENT  PROCESSOR  THROUGH  USE  OF 
THE  TRANSLATOR  WRITING  SYSTEM 

Central  to  the  FLTOPS  design  is  a statement  processor  that  functions 
as  the  central  control  mechanism  for  the  entire  precompiler  system.  The 
augmented  grammar  specification  rigorously  defines  the  interrelationships 
among  the  various  elements  of  the  system,  i.e.  which  and  when  primitives  are 
to  be  executed  for  any  of  the  control  statements  in  the  FCF  language. 

Providing  an  executable  program  that  performed  the  indicated  tasks  could 
be  time  consumming  if  it  were  to  be  developed  wholly  from  this  initial  state. 
The  existence  of  some  specialized  software  greatly  simplified  and  shortened 
this  development  effort.  The  Translator  Writing  System  (TWS)  produces  PL/1 
programs  from  inputs  that  appear  in  an  augmented  gramnar  format  similar  to 
that  used  in  the  FLTOPS  specification.  It  was  a simple,  straight-forward 
procedure  to  modify  the  FLTOPS  specification  graimar  into  a form  compatible 
with  the  input  format  of  the  TWS. 

The  use  of  the  TWS  in  the  development  of  the  functional  prototype  of 
FLrOPS  prov'ioed  several  distinct  advantagjs.  It  was  very  fast,  efficient 
and  relatively  inexpensive  to  employ.  The  format  of  the  augmented  grammar 
lends  itself  to  rapid,  modular  enhancements.  These  were  then  easily 
accommodated  for  by  simply  rerunning  the  TWS  with  the  new  modified  graimtar 
specification.  As  a result,  there  was  a one  to  one  correspondence  with 
changes  in  the  grammar  specification  and  the  statement  processor,  produced 
by  the  TWS,  that  controlled  the  precompiler  functions.  This  fast  and  easy 
update  niechanism  was  invaluable  in  providing  reliable  code  that  performed 
the  desired  functions.  An  additional  advantage  of  this  procedure  was  the 
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ease  with  which  errors  could  be  traced  and  corrected.  Once  learned, 
the  reading  of  the  augmented  grammar  specification  provides  a logically 
compact,  easily  read  format  for  describing  system  functions.  Processing 
errors  could  then  be  more  easily  found  with  reference  to  the  grammar  speci- 
fication than  the  resultant  PL/1  code  generated  by  the  TWS.  This  fact 
combined  with  the  proven  reliability  of  the  TWS  in  its  code  generation 
enabled  the  location  of  errors  in  system  processing  logic  to  be  found  and 
corrected  sooner  than  would  have  been  possible  through  conventional  de- 
bugging of  the  PL/1  code  generated  by  the  TWS.  The  impact  of  this  symbiotic 
effect  was  most  easily  seen  when  contrasted  with  the  debugging  procedures 
necessary  in  perfecting  the  procedures  written  for  each  of  the  primitives. 
Even  though  changes  to  the  grammar  far  exceeded  those  changes  made  to  the 
primitives,  total  debugging  effort  was  about  equal.  Such  performance  en- 
hancement has  established  from  a functional  standpoint  the  usefulness  of 
such  software  technology  as  the  TWS  in  system  validation  efforts  like 
this. 

Many  minor  and  a few  major  logical  errors  to  the  original  grammar 
specification  were  uncovered  as  a result  of  this  effort.  In  addition, 
several  enhanced  capabilities  were  introduced  to  provide  the  system  with 
greater  flexibility  and  usefulness  to  its  eventual  benefactors.  Each 
change  was  made  directly  to  the  grammar  and  reflected  in  the  functional 
prototype  by  use  of  the  TWS.  The  combination  of  the  statement  processor 
generated  by  the  TWS  from  the  augmented  grammar  specification  with  the 
procedures  developed  for  each  of  the  functional  primitives  provided  an 
integrated  program  that  emulated  actual  FLTOPS  operation. 

A-4  DEVELOPMENT  AND  EXECUTION  OF  FLTOPS  TEST  CASES 

Once  an  integrated  functional  prototype  of  the  FLTOPS  emulator  was 
available,  several  tests  were  formulated  to  be  executed  by  the  emulator. 


The  goal  of  these  test  scenarios  was  not  to  test  the  coding  efficiency 
or  accuracy  of  the  emulator,  but  to  test  the  FLTOPS  design  itself. 


Each  test  case  was  evaluated  for  proper  functional  behavior  of  the  emulated 
precompiler  and  with  respect  to  the  useability  of  the  FLTOPS  control  language 
with  respect  to  its  satisfaction  of  user  requirements.  In  addition  to 
those  tests  created  by  the  contrac'^or,  several  "real  world"  tests  were 
created  by  the  programming  staff  at  AFFTC,  Although  these  test  cases  them- 
selves proved  valuable  in  testing  the  design,  of  more  practical  and  imme- 
diate importance  was  the  hands  on  experience  they  provided  the  eventual 
users  of  the  system.  As  the  programmers  involved  tried  to  use  the  control 
language  to  accomplish  their  desired  goals,  they  were  able  to  provide  a 
valuable  interchange  of  ideas  that  resulted  in  several  important  enhance- 
ments to  the  design.  The  coupling  of  the  feedback  resulting  from  actual 
user  hands  on  experience  with  the  easily  modified  nature  of  the  augmented 
grammar,  provided  an  ideal  mechanism  for  insuring  that  the  design  was  a 
feasible  and  useful  expression  of  user  requi icemen ts . The  actual  results 
of  the  test  cases  pfovided  by  AFFTC  are  provided  to  the  individuals  in- 
vol ved. 


To  validate  the  design,  several  test  scenarios  were  developed.  Each 
utilized  to  some  extent  the  input  file/FCF  combination  shown  in  Figure  A-1 . 
Each  of  the  tests  was  designed  to  exercise  a certain  subset  of  the  FLTOPS 
control  language.  Those  elements  of  the  language  added  as  a result  of 
this  effort  may  not  be  completely  tested  although  all  have  been  included 
in  the  validation  package.  Figures  A-2  through  A-8  exhibit  the  test  cases 
as  actually  executed.  The  following  paragraphs  briefly  describe  some  of 
the  salient  features  of  each  example.  The  changes  that  were  made  as  a 
result  of  these  tests  and  those  enhancements  made  due  to  perceived  in- 
adequacies in  the  original  design  are  given  in  the  following  section. 

Test  cases  A-2,  A-3  exercise  symbol  table  operations  including  the 
use  of  tables  defined  as  arrays.  Note  that  sophisticated  usage  of  indirect 
pointers  as  well  as  expected  table  manipulations  were  tested.  Most  table 
operations  were  exercised  in  some  fashion  in  these  tests.  Time  did  not 
permit  exhaustive  testing  of  all  possible  combinations  permissible  in 
FLTOPS  symbol  table  operations.  All  table  operations  tested  performed 
according  to  specification  requirements  as  appear  in  the  body  of  this 
report. 
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CDMSTAMTS 

HAV  = 25000 
GEOPHYSICAL.MODEL 
EARTH 

SPHERICAL 

NON_ROTATING 

GRAVITY 

VARIABLE 

REQUIREO_COMPUTATIONS 

E'<ERGY_HEIGHT 

INTERPOLATION.ROUTINE  « POLY 
TA8LE_INf0R'AAT10H 
ROWS  = 5 

DATA  = 0-  26.3  /*  COMMENT  */ 

5.  69.8 
11.  76.3 
17.5  39.1 
20.  99.7 

l'JTERPOLATION_VALUES  = 1 . 63 , 2 . 1 , 6 . 2 , 1 1 . 6, 1 9 .3 
STRING  'STRING  OF  CHARS 
SIGNEO.NUMBER  = -39.5 
SPECI AL_SYMBOLS  *♦-,() 

EQUATION  = (7.*5.*SaRT(Y/2.))**(5.3«-Z)-<A(7,3)  ♦P(ALT(5),K1  )*2.  ) 
PD_INPUT_TEST 

"string  'THIS  IS  A STRING* 

WORD  SYM30L_TA8LE  ENTRY 
SPECIAL_SYM30LS  •♦-(*)**/• 

plus"  ♦ 

MINUS  - 
L_PAR  C 
MULT  * 

R_PAR  ) 

EXP  ** 

DIVIDE  / 

NUMBER  97.967845 
SIGNED_NUMBER  -89.361 
FCF  : 

P MAIN; 

P SET(DE3UG  = 'ON') 

P SEKTRACE  = 'HIGHER') 

P SETCNOTES  = 'ON') 

P STATUSC 'FLTOPS  STATUS  AT  START  OF  TEST') 

SJSSS  INSERT  TEST  FCF  HERE 

P MESSAGECG, 'N:END  OF  FCF  TEST  PROCEDURE') 

P END  MAIN 


BASIC  INPUT/FCF  FILES  FUR  VALIDATION  TESTS 
FIGURE  A-1 
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P MESSACE(G, 'KiSTART  Of  SYMBOL  TABLE  TEST') 

P 00  TOR  SYMBOL  TABLE  SYM.TA9 

P SET(N  » 'TABLE  ENTRY*) 

P STATUS( 'INITIAL  VALUE  OF  N ',SYM_TAB,N) 

P DELETE(N) 

P STATUSCN  AFTER  DELE  TE  • , S Y M_T  A B,  N ) 

P SET(N='TA3LE  VALUE') 

P SETCMs'SYMBOL  ENTRY') 

P S£T<<  = 'IN  SYM^TAB') 

P STATUS( 'TABLE  AFTER  INITIAL  S E TUP ' , S Y «_T AB ) 

P REPLACE (SYM_TAB,N, 'ENTRY '^SJBSTR ING< VALUE <SYM_TAB,X ),5,7) ) 

P STATUSCN  A?TER  REPLACE  WITN  PART  OF  X ' , S YM  _T  AB  ,N ) 

P CATENATE(SYM  TAB,M,VALUE  (X ) ) 

P STATUSCN  AFTER  CATENATE  OF  X ' ,SY«_TAB,M) 

P REPLACE(SYM_TA9,M,VALUE(X),") 

P STATUSCN  AFTER  REMOVAL  OF  X'^SYM  TA8,N) 

P SET(N) 

P REPLACE  (a,  ", 'A  •) 

P STATUSCN  AFTER  PREFIX  A A 0 0 E 0 ' , S YM_T  AB  , IN ) 

P DELETE(X) 

P DELETE (SYN_TAR,N) 

P STATUS  CSY.N_TA8  AFTER  X AND  N OE  LE  T E D ' , S Y M_T  A B ) 

P SET(M  = <7.3  + 2.7>''*2> 

P SET(N  « 5.*N) 

» SET(A  = 'N  ' ) 

P ST ATUS ( 'SYM_TAB  AFTER  M,N,A  S E T ' , S YM_ TA 3 ) 

P SETFVALUECaT  = F2CI  + 10)*5  + iac*2) 

P STATUSCSVM_TAB  AFTER  INDIRECT  ENTER', SYM  TAB) 

P SET(0  = 'A'jT 

P SET(VALUE (VALUE (0))  ) 

P ENTER(a,0) 

P STATUSCSYM_TA8  AFTER  DOUBLE  INDIRECT  S E T ' , S Y M_T  AB  ) 

P END 

P SET(I=1) 

P DO  WHILE  I<»5 

P INCRENENT(I) 

P END 

P STATUSCVALUE  OF  I AFTER  I N C R £ N E N T ' , FL  TO  PS  , I ) 

P 00  WHILE  I>0 

P OECREMENT(I) 

P END 

P STATUSCVALUE  OF  I AFTER  OE  CR  E NE  NT  ' , FL  TOPS  , I ) 

P NESSAGECG, 'N: TEMPORARY  END  OF  SYMBOL  TABLE  TEST') 


FCF  FOR  SYMBOL  TABLE  OPERATIONS 
FIGURE  A-2 
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P MESSAGE (G, 'N: START  OF  ARRAY  TABLE  TEST') 

P SET(N=5) 

P DEFINE  TA8LE(4,5),ARRAY(N),TAB2(1,1) 

P /*  NOW  USE  THESE  TABLES  IN  VARIOUS  WAYS  *! 

P ENTER(TA32(1,1 ),97.5) 

P ENTER(ARRAY(1),'N'> 

P SET(VALUE(ARRAY(1))  = 20) 

P SETCI=1) 

P DO  WHILE  I <=  A 

P SET(J=1) 

P DO  WHILE  J<=5 

P ENTER(TABLECI,J),I*J) 

P INCRENENTC J ) 

P END 

o INCRENE.NT(I) 

END 

STATUS( 'TABLE  OUTPUT  AFTER  TABLE  SETUP') 

IF  TABLE(3,5)  > 0 THEN  ENTER<ARRAY(2) ,TA8LE (3,5) *2 ) 

ELSE  ENTER (ARRAY(2) ,2) 

ENTER{ARRAY(3),2) 

ENTER(ARRAY(A) ,3) 

IF  TABLE(ARRAY{3) ,3)  = T ABL E ( AR R A Y ( 3) , AR RA Y ( A ) ) THFN 
P ENTER(TA8LE<ARRAY(3) ,ARRAY(A)),TABLE(A,5)*3+N) 

P ELSE  MESSAGECG, 'WrTHIS  MESSAGE  SHOULD  NOT  BE  PRINTED') 

P CATENATE (ARRAY (1 ),' EW  ENTRY') 

P SET(N  = ARRAY(3)**ARRAY(A)+TA8LE(2,5)*TABLE(3,3) /TABLE  (1,A)  ) 

P IF  TABLE(1,2)  > ARRAY(3)  THEN  E N T E R ( AR R A Y( 5 ) , T AB LE ( 2 , A ) ) 

P ELSE  ENTER(ARRAY(5),2.0*TAPLE(2,4)) 

P STATUS ( 'SYHBOL  TABLES  AFTER  SOHE  CHANGES  NADE') 

o NESSAGE(G,'N:ENO  OF  ARRAY  TEST') 


FCF  FOR  ARRAY  TABLE  CONSTRUCTS 
FIGURE  A-3 
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Figure  A-4  shows  the  test  used  to  validate  those  commands  related 
to  DO  block  usage.  All  DO  types  were  exercised  in  various  combinations, 
including  nested  DO  blocks  and  DO  blocks  that  conditionally  should  be 
skipped.  As  in  all  tests  the  presence  of  MESSAGE  and  STATUS  statements 
monitor  the  progress  of  the  test.  This  test  was  successfully  executed  with 
requirements  as  specified  in  the  body  of  this  report. 

Figure  A-5  shows  the  test  scenario  used  in  validating  the  proper 
evaluation  of  IF. . .THEN. . .ELSE  constructs.  Since  these  can  be  among  the 
most  complicated  in  the  language,  a fairly  complicated  test  was  constructed 
to  ennumerate  many  of  the  possible  constructs.  Both  complicated  boolean 
constructs  and  boolean  constructs  with  imbedded  arithmetic  expressions 
were  tested.  Proper  evaluation  of  all  tested  constructs  was  achieved. 

The  evaluation  of  input  file  commands  is  shown  in  the  test  cases 
presented  in  figures  A-6  and  A-7.  Various  legal  combinations  for  both  the 
FIND  and  INPUT  statements  were  tested,  all  proving  eventually  successful. 

Of  special  note  in  figure  A-7  is  the  test  of  the  INVOKE  statement.  Two 
rules  were  written  which  together  would  read  in  any  legal  FORTRAN  arith- 
metic expression  and  save  it  in  the  preset  location.  The  rules  A_EXPR 
and  A_TERM  are  recursive,  a legal  construct  in  the  FLTOPS  control  language, 
and  as  such  prove  to  be  a comprehensive  test  of  invocation  handling  by  the 
precompiler.  In  addition,  the  rules  themselves  demonstrate  some  uses  of 
the  INPUT  statement,  both  conditional  and  required.  These  tests,  too,  were 
successfully  completed  bv  the  FLTOPS  emulator.  Several  minor  changes  were 
incorporated  into  the  original  specification,  however,  to  enable  proper 
execution  of  the  test. 

The  last  test  formally  executed  was  a test  of  the  OUTPUT  command, 
PASSl  and  PASS2  substitutions,  comment  cards  and  format  control.  Shown 
in  figure  A-8  is  the  FCF  used  in  this  test.  Although  not  lengthy,  it 
provided  sufficient  information  to  establish  the  correct  operation  of  the 
FLTOPS  output  processor.  Many  aspects  of  output  generation  need  further 
testing  not  possible  given  the  resource/time  constraints  of  this  effort. 


p 

p 

o 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

p 

D 

P 

P 

P 

P 

P 

P 

P 

P 

P 

P 

P 

P 

O 

P 

P 

P 

P 

P 

P 

o 

p 

p 

p 


HESSACECG, 'MrSTART  OF  DO  STATE'^ENT  TESTS') 

/*  00  BLOCK  TEST  */ 

SETCONE  = 1) 

IF  1 = O'^E  THE»4  00 

MESSAGEIG, 'N:START  OF  FIRST  00  BLOCK') 

SET(I  =1)  . . 

00  <<HILE  I <3  5 

IF  1=1  THEN  I1ESSA6E(G,'N:START  OF  00  WHILE  BLOCK') 
!iESSAGE<G, 'N:  THIS  MESSAGE  SHOULD  PRINT  5 TINES') 
INCRENENT(I) 

SET(J  ■ 1) 

SETCTEST  = 'T') 

DO  WHILE  J<»3  AND  TEST  = 'T* 

NESSAGEIG, 'NrTHIS  MESSAGE  PRINTS  3 FOR  1 ABOVE') 
IF  I = 5 AND  J = 3 THEN  00 

HESSAGE(G,'N:SWITCH  TEST  TO  F') 

SETITEST  = 'F') 

END 

ELSE  IF  I = 5 THEN  NESS AGE (6, ' N :I  = 5 AND  J < 3') 
INCREMENT(J) 

END 

END 

MESSAGEIG, 'NrCOMPLETION  OF  OUTER  00  WHILE  BLOCK') 

DO  FOR  SYNBOL  TABLE  00  TAB 
SETCONE  =1) 

SETCTWO  = 2*0NE) 

SETCTHREE  = 3*TW0) 

SETCFOUR  = 4 * THREE) 

IF  THREE  <=  FOUR  THEN  DO 
SET(THREE) 

ENTER(a,FOUR) 

NESSAGECG, 'NzTHREE  SET  EQUAL  TO  FOUR') 

END 

END 

END 

ELSE  00 

MESSAGECG, 'NrALTERNATE  PATH  TAKEN  lOONE') 

00  FOR  SYMBOL  TABLE  OO.TAB 
SETCONE  = 10) 

SETCTWO  = Z.^ONE) 

SETCTHREE  = 3*TW0) 

SETCFOUR  » 4.0  * THREE) 

END 

END 


FCF  FOR  DU  BLOCK  STRUCTURES 
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P '4ESSA6E(G,'N:ENO  OF  LARGE  00  BLOCIC') 

P FIN0<00_1MPUT_TEST>  ERROR:  00  END 

P 00  FOR  EACH  SUBNOOE  OF  i 

P INPUT(UORO)  ERROR:  00  ENO 

P SET{*) 

P INPUTCCONSTANT  OR  STRING  OR  H0R0> 

P ENTER(a,*> 

P ENO 

P STATUS! "SYNBOL  TABLES  WHEN  SUBNODE  INPUT  CONPLETEO') 

P 00  FOR  SYN80L  TABLE  OO^TAB 

P SET(NOOES  » 0) 

P DO  FOR  EACH  SUBNOOE  OF  DO_INPUT_TEST. SPECIAL  SYMBOLS 

P INPUKWORO)  ERROR;  DO  END 

P SET!*) 

P INPUT!'*'  OR  ')'  OR  '!'  OR  '**'  OR  '/'  OR  '*'  OR 

P ERROR;  MESSAGE ! G, ' W: ILLEGAL  SPECIAL  SYMBOL  IN  INPUT') 

P ENTERCa,*) 

P INCREMENT!NOOES> 

P END 

P ENO 

«>  STATUS! 'SYMBOL  TABLES  AFTER  SU8N00ES  OF  SPECIAL  SY'ipCLS  READ') 

P MESSAGE!G, 'N:ENO  OF  DO  BLOCK  TEST') 
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'iESSAGE(G,'N;START  Of  IF  STATE^EXT  TEST') 

/*  BOOLEAN  EXPRESSIONS  WITHIN  IF  STATEMENTS  */ 

F INO(CONSTANTS) 

/*  IF  STATEMENT  Rl  */ 

ENTER<IF_TA9,*) 

IF  INPUT(WORO)  THEN  ME S SAGE (6 , ' W : F A I LURE  IN  IF  #1') 

ELSE  DO 

INPUTCEND  OF  NODE')  ERROR:  ME  SS  AGE  <G  W : ERROR  IN  IF  «1  ' ) 
MESSAGEIG, 'NrCORRECT  PATH  TAKEN  IN  IF  *1') 

END 

If  NODE  EXISTSIGEOPHYSICAL  MODEL. EARTH .NON_ROTATING)  THEN 
MESSAGEIG, 'NiCORRECT  IDENT  OF  NODES  IN  IF  «2') 

/*  IF  STATEMENT  #3  */ 

IF  NOT  SYNBOL_EXISTS(IF_TAB, CONSTANTS)  THEN  MESSAGE 
(G, 'WtINCORRECT  BRANCH  ON  NOT  CONDITION') 

ELSE  DO  FOR  SYMBOL  TABLE  IF_TA3 
SETICONSTANTS  = 97.5) 

MESSAGEIG, 'N:CORRECT  BRANCH  ON  IF  #3') 

SETISTRING  » 'ARBITRARY  •♦■SIX  STRING') 

END 

/*  If  STATEMENT  R4  */ 

STATUSCIF  TAB  AFTER  IF  STATEMENT  #3') 

IF  TABLE_EMPTY(IF_TAB)  THEN  DO 

MESSAGE (G, 'N: IF  TAB  EMPTY  — *4') 

SET(I»C) 

DO  WHILE  I <s  5 

CATENATEd  F_TAB,CONST  ANTS,*) 

INCREMENTC  I) 

END 

END 

ELSE  CLEAR. TABLElIf.TAB) 

STATUS! 'IF'tAB  AFTER  IF  STATEMENT  *4') 

/*  TEST~OF  RELATIONAL  CONSTRUCTS  */ 

FINO(CONSTANTS.HAV)  ERROR:  DO  END 
INPUT! '=') 

INPUT!CONSTANT) 

ENTER  !IF_TA8,HAV,*) 

/*  if'statement  /»5  */ 

IF  VALUE!IF  TAB,HAV)  » 230C0  THEN  MESSAGE 

!G,'N:HAV  IDENTIFIED  AS  EOUALING  23003') 

ELSE  DO  WHILE  VALUE !I f. TAB, HAV)  < 23000 
ENTER!IF_TAB,HAV,VALUE!I F_TAB,HAV)*2.  ) 

END 

/*  If  STATEMENTS  #6,7,8  */ 

FOR  SYMBOL  TABLE  If.TAB 

IF  27.9*8.736.5  <«  HAV  THEN  SET!HAV3  = HAV/2.) 

IF  HAW  <>  25000  THEN  ME SS AGE  ! G , ' N : H A V <>  23000') 

IF  HAW  < 23000  THEN  ME SS AGE ! G , ' N : HA V < 23CCO  #R') 

IF  WALUE!FLT0PS, FUNCTION)  ■ 'FULL*  THEN  DO  END 
ELSE  MESSAGE!6,'W:FLT0PS  FUNCTION  NOT  SET  TO  FULL') 

END 


DC 
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» '1ESSAGE(G,'N:TEST  OF  NESTED  IF  S T A T E'^ENT  S ' ) 

B /*  IF  STATEMENT  *10  */ 

P IF  VALUE(IF_TA0,HAV)  > 1C  THEN 

P IF  VALUEd  f“tAB,HAV>  > 100  THEN 

P IF  VALUE(IF^TA3,HAV)  > 1000  THEN 

P IF  VALUE(IfItA8,HAV)  > 1C000  THEN  00 

P MESSAGE(G, 'N:VALUE(I F_TA8,HAV)  > 1C000') 

P END 

P ELSE  MESSAGE(G,'N:VALUE(IF_TA3,HAV)  <=  1 CDOO ' ) 

P ELSE  liESSAGECG, 'NzVALUEd  F~TA9,HAV)  <*  1003') 

P ELSE  l*ESSAGE(G,'N:VALUEdF_TAB,HAV)  <=  ICO') 

P HESSA6E(G, 'N:END  OF  NESTED  IF  TEST') 

P I*  TEST  OF  TRICKY  NESTED  IF  */ 

P /*  IF  STATEMENT  A 11  */ 

P IF  SYMBOL_EXISTSdF  T A8  ,NOT  _THER  E ) THEN  PESSAGE 

P (G,* JrILLEGAL  STATEMENT  BRANCH  *11') 

P ELSE  IF  MOT  TABLE.EMPTY (I F_TA3)  THEN 

P IF  TABLE  EMPTYdF_TAB)  THEfS  DO  END 

P ELSE  IF  VALUcdF  TAB^HAV)  <>  3 THEN  MESSAGE 

» (G^'NzCORRECT  EXECUTION  OF  #11') 

P ELSE  DO  END 

P ELSE  MESSAGECG,' WiTABLE  IF_TA3  TESTS  EMPTY  *11') 

P MESSAGE(G^'N:TEST  OF  COMPLICATED  BOOLEAN  EXPRESSION') 

B /*  TEST  OF  COMPLICATED  BOOLEAN  EXPRESSIONS  *12-A15  *! 

P IF  1*1  AND  7>4  THEN  MESSAGE 

P (S,'N:1  = 1 AND  7>4  *12') 

P IF  1<1  OR  7>4  THEN  MESSAGE 

P (G,'N:1<1  OR  7>4  *13') 

P IF  NOKKI  OR  7>4)  THEN  MESSAGE  (G, 'WrINCORRECT  PATH  — *14') 

P ELSE  MESSAGEIG, 'NzCORRECT  EVALUATION  *14') 

P IF(1=1  AND  7>4)  AND  N0T(1<1  OR  7>4)  THEN  MESSAGE 

P (G,'W:INCORRECT  PATH  — *15') 

B ELSE  MESSAGEIG, 'NzCORRECT  PATH  TAKEN  — *15') 

MESSAGE(G,'N:TEST  OF  ARITHMETIC  EXPRESSIONS  WITHIN  BOOLEAN') 
IF  (15.5>4.5)*(4*1 .)  > 16.2*5.  AND  <6 . 3*3. 7) *1 0 . < 85  THEN 
MESSAGE(G,'W:ERROR  IN  PROCESSING  IF  *16') 

P ELSE  MESSAGE <G, 'NzCORRECT  EVALUATION  — *16') 

B /*  IF  STATEMENT  *17  */ 

P IF  N0T((7.*3.)*(5.-4.)  < 9)  OR  7>8  THEN  MESSAGE 

P (G,'N:CORRECT  EVALUATION  --  *17') 

P ELSE  ,MESSAGE(G,'U:IF  *17  IMPROPERLY  EVALUATED') 

P IF  NOT  (7.*3.)*(5.-4.)  < 9 OR  7>8  THEN  MESSAGE 

B (G, 'NrCORRECT  PATH  TAKEN  --  *18') 

P ELSE  MESSAGE(G,'W;INCORRECT  EVALUATION  --  *18') 

P IF  (((7*3)*10)  = 100)  THEM  MESSAGE 

B (G,'N:CORRECT  EVALUATION  — *19') 

P MESSAGEIG, 'NxENO  OF  IF  STATEMENT  TEST  •) 


FCF  FOR  CONDITIONAL  STATEMENTS 
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MESSAGE(G, 'NtBEGlNNING  OF  FI'JD  TEST') 

/*  TEST  OF  INPUT  FILE  SEARCH  — FIND  */ 

FI NO (GEOPHYSICAL  MODEL. EARTH. NON .ROTATING) 

ERROR:  MESSAGE (G, 'W rCANNOT  FIND  GEOPHYSICAL.MODEL , ET  AL') 
FINOCGEOPHYSICAL  MODEL)  ERROR:  DO  END 
FINOO. EARTH)  ERROR:  DO  END 
FINDCa.NON  ROTATING)  ERROR:  DO  END 
FINDdNTERPOLATION.ROUTINE)  ERROR:  DO  END 
SAVE.POINTER 

FIND(a. TABLE  INFORMATION. DATA)  ERROR: 

MESSAGE(g7'W:COULD  not  find  table  DATA') 

RESTORE.POINTER 

/*  NOy  FIND  A BROTHER  NODE  */ 

I*  FAILURE  TO  FIND  SPECIFIC  NODE  — TAKE  ERROR  PATH  */ 

FIND (GEOPHYSICAL  MODEL .VENUS .ELLIPSE ) 

ERROR:  MESS AGE ( G, ’ N :NODE  NOT  FOUND  — PLANNED  ERROR*) 
FINO(GEOPHYSICAL  MODEL) 

SAVE  POINTER 

FIND(a.EARTH.SPHERICAL.NEXT  LE VEL.ANOTHE R.LEVEL) 

ERROR;  MESSAGE(G, 'N:THIS  MESSAGE  SHOULD  BE  PRINTED') 

RESTORE  POINTER 

MESSAGE  (G, '.N:END  OF  FIND  STATEMENT  TEST') 


FCF  FOR  INPUT  SEARCH  STATEMENTS 
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P "^ESSAGECS^ 'NiBEGINNING  OF  INPUT  STATEMENT  TEST') 

P /*  TEST  OF  INPUT  STATEMENT  */ 

P F INOCCONSTANTS)  /*  POSITION  FILE  •/ 

P INPUTCENO  OF  NODE*)  /*  FORCE  TO  NEXT  NODE  */ 

P INPUT(UORO)  ERROR:  NESS AGE (G, ' 4 : C OULD  NOT  FIND  WORD*) 

P ENTERdNPUT,*) 

P INPUTCa')  ERROR:  DO  END 

P INPUT(NUM8ER>  ERROR:  DO  END 

P ENTERO,*) 

P FIND(INTERP0LAT10N_R0UTINE) 

P INPUrC*'  OR  WORD)  ERROR:  MESSAGE  (6, 'U  :DID  NOT  FIND  **) 

P INPUTCCONSTANT  OR  WORD  OR  STRING)  ERROR:  MESSAGE 

P (G,'W:OID  NOT  FIND  POLY') 

P FIND(STRING)  ERROR:  DO  END 

P INPUT(STRIN6) 

P ENTERCINPUT, STRING,*) 

P INPUTCEND  OF  NODE')  ERROR:  DO  END 

P INPUT(WORD)  ERROR:  DO  END 

P IF  * * •SIGNE0_NU«8ER'  THEN  DO 

P /*  ORDER  PURPOSELY  WRONG  */ 

P ENTER<INPUT,SIGNEO_NUMBER) 

P INPUTCSIGNED  NUMBER) 

» ERROR:  IF  INPUT('=')  THEN  INPUT(WORD) 

P ERROR:  INPUTCSIGNEO_NUMBER) 

P ERROR;  MESSAGE (G wTth I S MESSAGE  SHOULD  NOT  BE  PRINTED') 

P ELSE  MESSAGECG, 'W:010  NOT  FIND  THE  « SIGN*) 

P ENTERO,*) 

P END 

P /*  NOW  INPUT  CATENATED  INPUT,  I.E.  AN  INPUT  GROUP 

P FINO(INTERPOLATION_ROUTINE.INTERPOLATION_VALUES) 

P INPUT(  NUMBER  ^, ' NUMBER)  ERROR:  DO  END 

P /*  NOW  INPUT  SPECIAL  SYMBOLS  */ 

P FIK?<SPECIAL_SYMB0LS)  ERROR:  DO  END 

P ENTER 'INPUT,*) 

P DO  while  INPUTC*'  OR  OR  OR  OR  '('  OR  ')'  ) 

P CATENATEO,*) 

P END 

P INPUTCEND  OF  NODE')  ERROR:MESSAGE  (6,  ' W:  END  OF  NODE  WASNT  READ') 

P INPUT(WORO)  ERROR:  DO  END 

P EMTERCIMPUT,*) 

P INPUTC*')  ERROR:  00  END 

P MESSAGE <G, 'NrSTART  READING  AN  ARITHMETIC  EXPRESSION') 

* INVOICE  A EXPR 

» INPUTCWORO)  ERROR:  MESSAGE 

® (G,*N:THIS  MESSAGE  SHOULD  APPEAR  — END  OF  FILE') 

o MESSAGECG, 'N;ENO  OF  INPUT  STATEMENT  TEST*) 


FCF  FOR  IilPLT  READ  AND  RIUP  INVOCATION 
(Page  1 of  2) 

FIGURE  A-7 
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P 

A EXPR: 

1 

P 

IF  INPUTC^*  OR  •“•)  THEN  DO 

P 

CATENATEia,*) 

• 

p 

INVOICE  A_TERM 

p 

END 

o 

ELSE  INVOKE  A_TERM 

p 

DO  HHILE  INPuf('+'  OR  OR  **’  OR  '/'  0®  •*♦•) 

. j 

p 

CATENATEia,*) 

p 

INVOKE  A_TER11 

p 

END 

p 

END  A EXPR 

p 

A TER"«: 

p 

IF  INPUTCC)  THEN  DO 

p 

CATENATEO,*) 

p 

INVOKE  A_EXPR 

p 

INPUTC)')  ERROR:  NESSAGECI, 

i 

p 

•S;11ISSING  RIGHT  PARENTHESIS  IN  ARITHMETIC  EXPRESSION*) 

p 

CATENATED,*) 

p 

END 

p 

ELSE  IF  INPUKNUMBER)  THEN  CATENATE O^*) 

p 

ELSE  DO 

p 

INPUT(WORD)  ERROR:  MESSAGECI, 

p 

'S:ILLEGAL  TERM  IN  ARITHMETIC  EXPRESSION*) 

p 

CATENATED,*) 

p 

IF  INPUT<*(*)  THEN  DO 

? 

CATENATEia,*) 

• 

p 

INVOKE  A_EXPR 

p 

DO  HHILE  INPUT!*,*) 

p 

CATENATEO,*) 

p 

INVOKE  A_EXPR 

p 

END 

p 

INPUT!*)*)  ERROR:  MESSAGE!!, 

p 

*S:M1SSING  RIGHT  PARENTHESIS  ON  ARRAY  DECLARATION*) 

p 

CATENATE!a,*) 

p 

END 

p 

END 

p 

END  A_TERM 

• 

FCF  FOR  INPUT  RbAD  AND  RULE  INVOCATION 

1 

(PAGE  2 of  2) 

■ 

• 

FIGURE  A-7 
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1 

1 

P /*  TEST  OF  FORTRAN  OUTPUT  */ 

WRITE<1,1000)  INPUT 
1000  FORI1AT(40A2///) 

IF(N.EQ.3)  GO  TO  7 
C THIS  IS  AN  IN  LINE  COnnENT 

OINENSION  A(17,3) 

15  X * SQRT<7.3*10. )**(7.6+Y*M) 

A(3,5)  * EXP<A(1,2>>*5.>Z-3. 

P ENTER(PASS1,'/»JBUF*,'(J)  •) 

XiFJBUF  * YfJBUF  ♦ 5. 

EQUIVALENCE (JBUF (3)^10) 

X » 7.3  ♦ X #JBUF 

P 0ELETE<PASS1,'»J8UF'> 

P /*  NOW  SYNTHESIZE  A STATEMENT  */ 

P 0UTPUT(*25  CONTINUE',#) 

P OUTPUTCIF  (Y.EQ.O.)  CALL  SUBR  ( J ,X)  * , #) 

P OUTPUT('IOOO') 

P OUTPUT! 'FORMAT <15, 61 4.7,3 (3X, FI  0.4/) > ',#) 

P ENTERCOUT  T AB,STATENENT, ' I F (J .SE .7)  X=7.3*Z') 

P OUTPUT! *75', VALUECOUT  TAB, STATEMENT),#) 

P OUTPUT!COMMENTl,'  THIS  IS  A GENERATED  COMMENT',#) 

P SETCOUTPUT  = 'DATA') 

P 0UTPUT!C0L!6),7.3  FORMAT <F 5 .2) ,COL ! 21 ) , ! 3. 7+8 . 5) *5 . FORMAT!!),#) 

P MESSA6E!6,'M:END  OF  OUTPUT  TEST') 


FCF  FOR  SIMPLE  FORTRAN  OUTPUT 
FIGURE  A-8 
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The  following  section  details  the  major  changes  in  the  specification 
affected  by  the  validation  effort. 

A. 5 CHANGES/MODIFICATIONS  TO  FLTOPS  DESIGN 

As  a direct  result  of  the  validation  effort,  both  through  the 
test  cases  developed  at  AFFTC  and  those  developed  by  SAI,  many  minor 
and  several  major  modifications  to  the  FLTOPS  design  have  been  incor- 
porated into  the  specification  included  in  the  body  of  this  report.  Al- 
though all  changes  would  be  tedious  and  unproductive  to  document,  major 
modifications  and  enhancements  are  listed  here  to  provide  adequate  docu- 
mentation of  the  usefulness  of  such  an  effort.  All  changes  would  have, 
of  necessity,  been  made  eventually.  The  factor  of  importance  here  is 
that  changes/corrections  have  been  made  early  in  the  development  cycle 
where  they  can  be  incorporated  at  minimum  cost.  If  left  to  the  implemen- 
tation phase,  the  discovery  of  these  design  changes  may  well  have  resulted 
in  increased  span  time  to  delivery  of  an  implemented  system.  Instead,  the 
Air  Force  has  a functional  prototype  system  that  can  be  utilized  for 
training  and  development  purposes  for  actual  end  user  personnel  as  well 
as  provide  a continuing  medium  for  design  validation  and  bench  mark  development. 

Modifications  actually  are  separated  into  two  different  classes: 
those  changes  to  the  original  design  due  to  logical  inconsistencies  or 
omissions  in  the  original  design  and  those  changes  made  due  to  the  need 
for  additional  capability  not  originally  specified.  Figure  A-9  lists 
those  major  corrections  made  to  the  original  design.  Figure  A-IQ  provides 
a summary  of  major  additions  to  the  original  design. 

Several  rules  proved  to  be  written  inadequately  to  perform  the 
desired  function.  Notably,  the  00  FOR  EACH  SUBNODE  command  was  rewritten 
entirely  so  as  to  provide  for  proper  recovery  and  scanning  when  each  sub- 
node had  been  processed.  The  INVOKE  statement  was  also  written  so  as  to 
insure  that  it  properly  handled  not  only  invocations  that  were  to  be 
executed,  but  also  those  invocations  resulting  in  syntax  checking  and 
scanning  due  to  conditional  bypassing  of  FCF  code. 
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RULES  REWRITTEN: 

DO_FOR_EACH_SUBNODE_STATEMENT 

INVOKEJTATEMENT 

RULES  TO  WHICH  SIGNIFICANT  CORRECTIONS  WERE  MADE: 
STRINGJXPRESSION 
ARITHMETIC_EXPRESSION 
TABLE_EMPTY_STATEMENT 
SET_STATEMENT 
INCREMENT_STATEMENT 
DECREMENT_STATEMENT 
VALUE_FUNCTION 
ARRAYJLEMENTS 

RULES  TO  WHICH  MINOR  CORRECTIONS  WERE  MADE: 
DO_FOR_SYMBOL_TABLE_STATEMENT 
FIND_STATEMENT 
DEFINE_STATEMENT 
ARITHMETIC_PRIMARY 
FIND_lNPUT_NODE 
FIND_NODE_THIS_LEVEL 

(Not  included  specifically  on  this  list  are  changes  that 
were  needed  as  a result  of  the  significant  correction 
to  STRING  EXPRESSION.) 


DESIGN  CORRECTIONS  AS  A 
RESULT  OF  THE  FLTOPS  VALIDATION  EFFORT 

FIGURE  A-9 
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Although  major  rewrites  did  not  occur,  important  minor  corrections 
were  made  to  the  following  command  operations:  TABLE_EMPTY,  DEFINE,  SET, 
INCREMENT,  DECREMENT,  ARITHMETIC  EXPRESSION  processing,  STRING  EXPRESSION 
processing,  ARRAY  table  processing,  and  FIND  INPUT  NODE  processing.  Of 
special  note  is  the  change  incoprorated  into  STRING  EXPRESSION  processing. 
Although  only  several  lines  in  length,  all  statements  that  utilized 
STRING  EXPRESSIONS  in  their  syntax  format  had  to  be  modified  slightly. 

The  change  was  necessary  to  insure  that  the  following  condition  was 
satisfied: 

INVOKE  A 

ENTER{A,  B,  A) 

A rule  named  A is  invoked  in  the  first  statement.  A symbol  B in  table  A 
is  referenced  in  the  second.  In  this  instance,  the  string  A is  not 
entered  into  the  table  location  but  the  value  of  symbol  A in  the  default 
symbol  table.  This  operation  is  exactly  what  was  intended  in  the  original 
design  specification,  but  was  not  accomplished  because  the  grammar  was 
incorrect.  Since  nearly  half  the  rules  in  the  grarmar  were  in  seme  way 
modified  because  of  this  change,  it  was,  therefore,  very  important  that 
it  was  caught  early  as  it  may  have  had  an  adverse  effect  on  the  imnlemen- 
tation  effort.  In  addition,  minor  changes  were  also  made  to  insure 
proper  stack  operations  especially  with  respect  to  the  arithmetic  stack 
and  input  pointer  stack. 

As  depicted  in  figure  A- 10  many  more  changes  were  made  as  a result 
of  enhancements  to  the  original  design.  A principal  reason  for  these  en- 
hancements was  that  the  end  user  actually  formulated  and  solved  problems 
utilizing  the  capabilities  of  the  FCF  control  language.  As  problems  were 
encountered,  those  solutions  that  seemed  feasible  and  useful  were  incor- 
porated into  the  design.  Such  user/designer  interaction  during  the  design 
phase  served  the  dual  purpose  of  training  the  end  users  of  the  system  as 
well  as  providing  insight  into  what  capabilities  they  felt  would  be  helpful 
in  doing  their  job  better. 
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DESIGN  ADDITION 

RESULT 

I NO  EXJUNCTION 

Determination  of  the  starting  position  of  sub- 
string within  a string. 

LENGTHJU  NOTION 

Determination  of  number  of  characters  in  a string 
(includes  any  symbol  table  entry). 

DEFINE. ..AS... 

Provides  user  with  multiple  names  for  the  same 
table. 

DEFINE. . .AS  NULL 

Provides  ability  to  remove  multiple  table  names 
and/or  dimensions . 

Expanded  MESSAGE 

Provides  users  capability  to  output  symbol  table 
or  computed  values  along  with  messages. 

Expanded  INPUT 

Provides  users  with  the  capability  to  read 
multiple  INPUT  elements  simultaneously. 

Expanded  OUTPUT 

Provides  users  explicit  control  over  EOF  and  EOR 
marks,  comment  card  generation  and  format  control 
of  output  elements . 

FORMAT  Control 

Pr'ovides  users  format  control  over  elements  in- 
serted into  symbol  tables  or  output  via  the 

MESSAGE  or  OUTPUT  commands. 

Expanded  Boolean 
Expression 

Provides  users  with  additional  capabilities  in 
constructing  Boolean  Expressions,  including  any 

FIND  statement  or  STRINGJXPRESSION. 

Rules  Added  to  the  Design  Specification; 

DEFINED_ELEMENT.  INPUT_GROUP,  INDEX_FUNCTION,  LENGTH_FUNCTION, 
SIGNEU_NUMBER.  COLUMNJORMAT . FORMAT_STATEMENT . FORMAT_ELEMENT 

Primitives  Added  to  the  Design  Specification; 

.INDEX.  .LENGTH.  . S£TUP_TABLL_EgUI VALENCE , .NLlLL_OUr_rABLE . 
.ADJUST_COLUMN.  . FORMATES TRING 


Several  new  built-in  functions  were  added  to  the  design  and  the 
functions  of  several  other  control  statements  were  extended  as  a result 
of  the  validation  effort.  The  LENGTH  and  INDEX  functions  were  added  to 
provide  better  user  control  of  string  quantities.  These  combined  with  the 
SUBSTRING  function  and  REPLACE/ CATENATE  statements,  provide  a sophisticated 
repertory  of  string  manipulation  commands. 

The  function  of  the  INPUT  command  was  expanded  so  as  to  allow  the 
user  the  ability  to  catenate  input  requests  within  one  command  structure. 
Now  a word  and  number  can  be  read  in  one  operation,  INPUT(WORD  NUMBER). 
Although  functionally  equivalent  to  the  original  design,  the  inputing  of 
a SIGNED_NUMBER  is  controlled  by  the  grammar  and  not  as  a special  token 
class  in  the  input  lexical  analyzer.  As  a result,  the  user  can  input 
-39.7  either  as  INPUT(’-')  INPUT(NUMBER)  or  as  INPUT ( SIGNEDJUMBER ) . 

The  DEFINE  statement  was  expanded  to  serve  two  additional  purposes. 
With  the  DEFINE... AS  NULL  statement  the  user  can  eliminate  previous  dimen- 
sions or  equivalences  and  reuse  an  array  table  as  any  other  symbol  table. 
With  the  DEFINE. . .AS. . . statement,  the  user  can  establish  several  table 
names  to  refer  to  the  same  table.  This  greatly  simplifies  the  use  of 
rules  that  may  be  Invoked  from  several  locations  with  the  intent  of 
accessing  or  storing  different  table  data. 

The  CATENATE  statement  was  modified  to  allow  for  multiple  catena- 
tions at  the  same  location  with  one  CATENATE  command.  This  reduces  the 
number  of  statements  needed  to  accomplish  some  tasks  and  has  proven  to  be 
a useful  extension. 

Like  the  CATENATE  statement,  the  MESSAGE  statement  syntax  has  been 
modified  to  provide  greater  feasibility  to  the  user.  A string  literal 
identifying  the  type  and  severity  of  the  message  is  required  but  now  any 
symbol  table  value  or  arithmetic  calculation  can  be  output  directly  by 
the  MESSAGE  command. 
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The  largest  addition  to  the  design  has  been  with  respect  to  the 
OUTPUT  statement.  The  OUTPUT  has  been  expanded  to  permit  explicit  control 
over  END  OF  FILE  and  END  OF  RECORD  marks,  the  explicit  generation  of  COMMENT 
cards  and,  more  importantly  explicit  FORMAT  control.  The  FORMAT  control 
on  OUTPUT  allows  both  column  control  and  FORTRAN  like  formatted  data  con- 
trol. The  introduction  of  the  format  control  on  OUTPUT  prompted  the 
recognition  of  a similar  need  for  whenever  a value  is  entered  into  a 
symbol  table.  As  a result,  the  FORTRAN-1  ike  format  control  was  also  made 
optional  for  all  symbol  table  operations  in  which  data  is  being  inserted 
into  a symbol  table. 

As  is  evident,  very  nearly  all  the  rules  in  the  original  design 
specification  have  been  modified  so  as  to  conform  to  the  original  and  en- 
hanced requirements.  The  important  difference  with  the  new  specification 
contained  in  the  body  of  this  report  is  that  it  has  been  validated  that 
It  meets  user  requirements.  Furthermore,  the  existence  of  the  functional 
prototype  Insures  that  further  testing  and  modifications  can  continue  at 
a cost  effective  rate  until  implementation  begins.  In  addition,  the 
functional  prototype  can  be  used  throughout  the  implementation  phase  to 
develop  and  test  actual  modules  that  are  needed  to  bench  mark  the  imple- 
mented FLTOPS.  As  a result,  the  prototype  provides  the  mechanism  whereby 
the  implemented  FLTOPS  can  be  effectively  used  from  the  time  of  its  in- 
stallation. 
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EXTENDED  FLTOPS  VALIDATION  EFFORT 

B.l  INTRODUCTION 

The  original  validation  effort  succeeded  in  verifying  and  validating 
the  worth  and  useability  of  the  FLTOPS  design.  However,  inherent  in  the 
validation  effort  were  extensive  changes  to  the  original  design 
which  necessitated  both  changes  to  the  design  specification  and  the 
emulator  package  that  performed  the  FLTOPS  functions.  Many  of  these  changes 
to  the  design  were  not  adequately  tested  in  the  initial  validation  effort 
both  because  of  time  and  resource  constraints. 

In  addition,  an  FCF  provided  by  AFFTC/DOEDM  personnel  that  custom- 
ized a portion  of  the  UFTAS  system  known  as  LINK4,  had  not  yet  been  success- 
fully run  by  the  end  of  the  initial  validation  effort.  The  complexities 
of  designing  an  FCF  by  those  unfamiliar  with  the  operation  of  the  host 
language  which  in  and  by  itself  was  subject  to  change  throughout  the 
validation  effort,  combined  with  an  emulator  that  had  not  been  thoroughly 
tested,  caused  many  slow  downs  to  a straight  forward  but  subtly  complex 
task. 

Both  of  the  above  tasks,  were  deemed  to  be  sufficiently  important 
to  warrant  a small  extended  effort  of  the  validation  phase  of  the  contract. 
The  objectives,  then,  of  this  phase  of  the  contract  were  two-fold: 

•provide  continued  emulator  support  of  AFFTC/DOEDM  personnel. 
Specifically,  this  was  to  result  in  successful  processing  of  the 
LINK4  FCF  using  four  input  test  cases  as  provided  by  AFFTC. 

•Provide  enhanced  FCF  test  cases  which  would  include  tests 
of  those  elements  of  the  design  added  during  the  validation 
phases  of  this  contract. 

The  following  sections  discuss  the  work  done  on  each  of  these  tasks. 
Although  minimal  compared  with  earlier  validation  efforts,  several  changes 
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were  also  made  to  the  design  specification  as  a result  of  this  effort. 
The  concluding  section  of  this  appendix  details  these  changes. 

B.2  EMULATOR  SUPPORT  ACTIVITY 


The  emulatory  built  as  a task  under  the  initial  FLTOPS  validation 
effort  provided  some  valuable  insights  as  to  areas  in  which  the  design  of 
the  FLTOPS  system  could  be  strengthened.  Also  key  to  insuring  that  the 
design  would  provide  functional  support  for  real  world  problems  was  the 
development  of  FCF's  by  the  end  users  of  the  system.  The  LINK4  FCF  gener- 
ated by  AFFTC/DOEDM  personnel  provided  an  excellent  example  of  a real-world 
problem  that  demonstrated  the  effectiveness  of  the  concept.  Although  the 
FCF  was  received  as  a part  of  the  initial  validation  effort,  its  complexity 
combined  with  minor  errors  in  the  emulator  caused  successful  completion 
of  the  LINK4  test  runs  to  be  postponed  until  this  phase  of  the  contract. 
What  follows  are  some  reflections  and  results  of  this  initial  real-world 
operation  of  the  FLTOPS  concept.  Of  particular  note  are  the  comparisons 
listed  in  table  B-1  and  discussed  in  section  B.2. 3. 

B.2.1  PROCESSING  RESTRICTIONS  OF  THE  FLTOPS  EMULATOR 

The  emulation  of  the  FLTOPS  functions  for  purposes  of  test  and 
validation  of  the  design  was  accomplished  through  the  creation  of  an 
emulator.  This  "quick  and  dirty"  program  performed  its  mission  in  the 
desired  fashion  and  was  invaluable  in  analyzing  and  validating  the  design. 
However,  because  it  was  an  emulation  and  not  an  implementation  of  the 
design,  it  had  limitations  that  immediately  came  to  bear  upon  the  success- 
ful running  of  the  LINK4  FCF.  Among  these  limitations  were: 

1)  The  total  limit  on  size  of  an  FCF,  initially  set  to  400, 
later  increased  to  2100,  card  images.  The  design  does  not 
establish  a limit. 

2)  The  total  limit  on  size  of  a symbol  table  entry,  initially 
set  to  50,  later  increased  to  100  characters.  This  was 
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stm  not  sufficient;  changes  to  the  FCF  were  necessary 
to  work  around  this  emulator  restriction.  The  design  does 
not  establish  a limit  for  length  of  symbol  table  entries. 

3)  The  total  number  of  tables  was  initially  set  to  20  and 
later  increased  to  40.  No  limit  is  identified  in  the 
design. 

4)  The  total  limit  on  the  number  of  symbol  table  entries  was 
initially  set  to  200  and  later  Increased  to  300.  No  limit 
is  identified  in  the  design. 

5)  Limits  were  violated  on  various  internal  operations  stacks. 

Each  was  increased  appropriately.  No  stack  size  limits 
have  been  identified  in  the  design. 

6)  The  emulator  does  not  process  comments  between  rules  and 
at  the  beginning  of  the  input  file.  Actual  implementa- 
tion will  allow  conments  to  appear  anywhere. 

Each  of  the  above  restrictions  provided  some  slow  down  in  the  even- 
tual successful  processing  of  the  LINK4  FCF.  An  actual  implementation 
would  remove  each  restriction  in  a satisfactory  manner.  Time  and  purpose 
did  not  allow  the  emulator  to  be  so  configured.  The  importance  of  identi- 
fying these  restrictions  is  that  it  identifies  an  area  of  concern  for  the 
implementor,  and  it  provides  the  rational  for  some  changes  that  were  neces- 
sary in  the  LINK4  FCF  so  that  it  could  be  processed. 

B.2.2  THE  LINK4  FCF  -THE  SOURCES  OF  ERROR 

Just  as  the  emulator  was  changed  in  a number  of  instances  to  accom- 
modate the  FCF,  so  too  was  the  FCF  changed  in  a number  of  instances  to 
promote  its  successful  processing.  As  in  any  programming  language,  a 
certain  number  of  coding  errors  are  expected  as  a result  of  the  complexity 
of  the  problem.  The  LINK4  FCF  was  changed  in  a number  of  places  because 
of  coding  or  syntax  errors,  in  several  other  places  to  eliminate  cumber- 
some or  faulty  use  of  the  language  and  in  several  other  places  to  work 
around  emulator  restrictions  (see  above).  In  total,  well  over  100  lines 


of  original  code  were  corrected  or  modified  in  some  way  to  facilitate 
processing.  Although  this  may  seem  like  a great  deal,  overall  it  was 
less  than  10  percent  of  the  total  FCF  that  needed  changing.  Many  changes 
were  of  a pure  syntactic  nature,  I.e.  missing  parenthesis,  commas, 
apostrophes,  etc.  Other  changes  were  due  to  faulty  coding  logic,  (e.g., 

SAVE-POINTER  command  out  of  sequence  with  the  corresponding  RESTORE- 
POINTER  command,  the  value  of  a parameter  counter  being  Inadvertently 
set  to  the  wrong  value,  etc.).  These  types  of  errors  are  to  be  expected 
in  any  coding  exercise.  The  Importance  here  Is  that  the  capability  to 
trace  the  cause  of  error  should  be  greatly  enhanced  by  the  debugging 
capabilities  of  the  language  at  hand.  The  existence  of  such  errors 
provided  a reason  and  means  to  test  the  utility  of  the  design  debugging 
features,  notably  the  TRACE,  and  DEBUG  switches  and  the  STATUS  and  ASSERT 
commands.  As  discussed  below,  some  changes  were  made  and  Insights  gained 
in  this  area  as  a result  of  this  debugging  effort. 

Of  most  Importance  with  regard  to  the  design  are  those  changes  made  to 
correct  Improper  uses  of  the  language.  At  the  time  that  this  FCF  was  written, 
certain  enhancements  to  the  design  had  not  yet  been  Implemented.  As  a 
result,  an  attempt  was  made  to  utilize  certain  Improper  language  constructs 
to  perform  necessary  functions.  Examples  of  these  constructs  are  as  follows; 

IF  VALUE  {VALUE  (UNITS)  (!))<>  ' ' then  . . . 

CATENATE  (DEFAULT,  VALUE  (DATA2)  ), 

LENGTH  (VALUE  (UNITS)  (I)  ),  'H',  VALUE  (UNITS)  (I)  ) 

The  syntax  of  the  VALUE  function  does  not  permit  the  kind  of  Indirect 
table  name  reference  Implied  by  these  constructs.  However,  the  need  for 
this  kind  of  Indirect  reference  was  part  of  the  motivation  for  adapting 
the  DEFINE  statement  to  allow  for  table  name  equivalencing.  The  above 
statements  were  transformed  Into  the  following  kinds  of  constructs: 

* T. 

I. 
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DEFINE  UNITS  AS  VALUE  (UNITS) 

h A TABLE  UNITS  IS  EQUIVALENCED  */ 

/*  TO  THE  TABLE  NAME  IDENTIFIED  V 
/*  BY  THE  ENTRY  UNITS  IN  THE  DEFAULT  */ 

/*  SYMBOL  TABLE  */ 

IF  UNITS  (I)  <>  ' • THEN  . . . 

» 

CATENATE  (DEFAULT,  VALUE  (DATA2), 

LENGTH  (UNITS  (I)  ),  'H',  UNITS  (I) 

DEFINE  UNITS  AS  NULL 

/ * REMOVE  THE  TABLE  EQUIVALENCE  */ 

The  resulting  code  is  much  more  readable,  compact  and  correct. 

Another  possible,  more  subtle  misconception  involved  nesting  of 

VALUE  statements.  The  statement 

IF  VALUE  (VALUE  (UNITS)  (!))<>''  THEN  . . . 
could,  using  the  above  procedures,  be  changed  directly  into 

IF  VALUE  (UNITS  (I)  ) <>  ' ' THEN  . . . 
but  this  is  an  unnecessary  use  of  the  VALUE  function.  The  result  of  this 
expression  is  the  same  as  the  following: 

IF  UNITS  (I)  <>  ' ' THEN  . . . 

The  language  constructs  are  such  that  "implied  value"  statements 
can  be  used  in  situations  such  as  this  where  there  is  no  ambiguity  in 
meaning. 
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still  other  changes  were  necessary  in  the  LINK4  FCF  to  accommodate 
inadequacies  in  the  emulator.  Specifically,  the  length  of  symbol  table 
entries  was  restricted  to  100  characters.  The  building  of  various  common 
block  statements  as  well  as  data  statements  required  symbol  table  entries 
consistently  longer  than  what  was  available.  Because  it  would  have  re- 
quired significant  effort  to  alter  the  emulator  to  handle  arbitrarily  long 
strings,  it  was  decided  to  modify  the  original  FCF.  The  method  adopted 
utilized  array  tables  in  place  of  the  single,  long  table  entry  previously 
required.  Upon  output,  a loop  was  created  which  output  all  non-empty 
table  entries  before  the  statement  terminator  was  issued.  Although  some- 
what more  lengthy  than  the  original  method,  this  procedure  clearly  demon- 
strated the  adaptability  of  the  FCF  control  language. 

Because  the  LINK4  FCF  was  a real  world  example  whose  intent  was 
to  customize  FORTRAN  as  opposed  to  a validation,  of  the  design  it  proved 
to  be  a very  good  test  of  the  solidarity  of  the  emulator  itself.  Several 
implementation  concerns  immediately  surfaced  because  of  this  exercise. 
Especially  important  was  the  provision  of  adequate  internal  safeguards 
against  overflow  and  stack  size  violations.  Of  particular  importance  was  the 
need  for  providing  sufficient  stack  sizes  to  inhibit  overflow  conditions. 
Other  concerns  brought  to  light  were  the  need  for  different  default  con- 
version guidelines  when  arithmetic  calculations  resulted  in  a value  being 
converted  to  string  format.  The  emulator  uses  the  Pl/1  guideline  which 
invariably  allows  for  too  many  leading  blanks.  Some  concerns  regarding 
the  form  of  the  FORTRAN  output  were  also  brought  to  light.  Although 
significant  enhancements  were  made  to  the  emulator's  ability  to  output 
exactly  what  was  input,  there  is  still  a need  to  have  statements  in 
which  a substitution  has  been  made  written  without  having  variable  names 
split  between  lines,  without  large  blank  spaces  in  the  middle  of  lines, 
and  without  other  unsightly  output  forms. 

Of  particular  importance  in  this  exercise  was  the  insight  derived 
from  debugging  the  FCF.  Although  the  debugging  tast  was  decidedly  more 


complicated  because  of  the  need  for  concurrent  debugging  of  the  FCF 
and  the  emulator  package,  the  overall  impact  was  to  provide  necessary 
experience  concerning  the  content  and  level  of  useful  information. 

Both  the  TRACE  and  STATUS  debugging  facilities  proved  invaluable 
in  system  debugging.  The  STATUS  command  has  sufficient  flexi- 
bility to  make  it  very  valuable  in  monitoring  FCF  execution  per- 
formance. The  TRACE  feature,  too,  has  proved  to  be  very  useful.  However, 
the  level  of  printout  received  was  decidedly  unbalanced  prior  to  execu- 
tion of  this  FCF.  Many  things  that  would  be  useful  to  the  system  debugger 
were  being  printed  out  at  TRACE  level  HIGH  where  they  simply  obscurred 
readability.  Similarly,  several  items  that  should  have  been  included 
at  a TRACE  level  of  LOW  were  only  turned  on  when  set  to  HIGH.  The  total 
debugging  process  provided  some  valuable  insights  in  both  what  and  when 
certain  items  became  useful.  Surely  more  experience  will  be  necessary 
in  establishing  all  debugging  guidelines,  but  this  experience  has  provided 
a big  step  in  identifying  levels  of  useful  debug  output. 

B.2.3  COMPARISON  OF  TEST  RESULTS 


The  LINK4  FCF  was  processed  using  the  four  test  cases  as  provided 
by  AFFTC.  The  resulting  FORTRAN  code  was  subsequently  compiled  at  the 
AFFTC  computer  facility.  The  number  of  lines  of  code  and  the  memory 
locations  required  for  each  of  the  four  cases  were  then  compared  with  the 
original  LINK4  as  used  in  UFTAS.  Table  B-1  lists  these  comparisons  as 
derived  from  the  actual  compilation  statistics.  As  easily  seen  from  the 
table,  dramatic  reductions  in  both  the  number  of  lines  of  code  and  in 
memory  requirements  resulted  in  several  test  cases.  A good  portion  of  the 
savings  resulted  because  of  fairly  simple  operations.  Note  that  in 
Test  2-4  the  number  of  values  stored  in  comnon  were  cut  significantly 
from  the  original.  This  savings  was  primarily  a result  of  eliminating 
the  need  for  dimensioned  variables  in  those  instances  where  only  the 
first  entry  of  an  array  was  actually  used.  This  savings  will  result  not 
only  in  decreased  core  requirements,  and  hence  a greater  likelihood  of 
qualifying  for  faster  access  to  computer  resources,  but  also  in  faster 
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run  times  as  branching  and  array  position  calculations  are  eliminated. 

The  other  large  segment  of  code  that  was  eliminated  resulted  from 
the  ellmenatlon  of  those  subroutines  not  needed  for  certain  types  of  analysis. 
Tests  3 and  4 resulted  In  eliminating  fairly  large  subroutines  (e.g.,  734 
lines  of  code  In  the  original  version  of  DALAG)  from  even  being  processed  and 
subsequently  loaded  with  the  LINK4  package.  Such  savings  could  easily  result 
in  eliminating  the  need  for  one  or  more  overlays  for  a particular  analysis. 

Note  also  that  In  every  subroutine,  the  number  of  lines  of  code  was 
changed  indicating  some  structural  changes  in  the  way  elements  were  processed. 
Although  the  details  of  these  changes  may  be  quite  varied  among  the  test  cases, 
more  than  likely  the  readability  and  processing  speed  of  each  routine  was 
greatly  enhanced  by  the  removal  of  superflous  code  not  relevant  to  the 
application. 

Figures  B-2  and  B-3  provide  listings  of  the  input  files  used  for 
test  cases  one  and  four  respectively.  Note,  that  the  Inputs  are  readable  and 
understandable  by  those  who  most  need  to  know  what  the  code  Is  doing,  the 
flight  test  engineer.  Such  self  documentation  of  the  code  makes  Immediately 
clear  what  Is  supposed  to  be  accomplished  by  executing  this  FORTRAN  code. 

Note  also  the  similarities  between  the  two  Inputs.  A few  change  in  the  input 
file  reduces  greatly  the  amount  of  code  produced.  Although  dependent  on  FCF 
construction,  this  attribute  demonstrates  the  power  and  flexibility  of  the 
Input  file  associated  with  each  FCF.  Inputs  for  tests  two  and  three  are 
very  similar  In  content  to  test  four  and  are  omitted  here.  Similarly,  the 
LINK4  FCF  Is  quite  lengthy  and  has  not  been  reproduced  here. 
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riEMORY 


WORDS  IN  DECIMAL  (OCTAL) 


Oriqlnal 

Ttst  1 

Test  2 

Test  3 

Test  4 

LINK4 

S6 

(70) 

54 

(66) 

26 

(32) 

26 

(32) 

26 

(32) 

INPUT4 

1393 

(2.561) 

1160 

(3.838) 

1)45 

(2.171) 

1102 

(2.116) 

1105 

(2.121) 

OALAG 

734 

(1  .336) 

673 

(1.241) 

— 

— 

— 

SFEXT 

466 

(T24) 

453 

(705) 

363 

(553) 

314 

(472) 

250 

(372) 

W.UPR 

IBB 

(274) 

127 

(177) 

115 

(163) 

— 

— 

SOABB 

64 

(100) 

66 

(102) 

66 

(102) 

— 

— 

SNXNZ 

280 

(430) 

105 

(151) 

82 

(122) 

82 

(122) 

62 

(122) 

COMMON 

4570 

(10.633) 

4239 

(10.217) 

1090 

(2.102) 

1102 

(2.116) 

1105 

(2.121) 

TOTAL 

7753 

(17.111) 

6877 

(15.335) 

2887 

(5.507) 

2626 

(5.102) 

2568 

(5.010) 

SAVINGS  0%  in  63S  662  67S 


LINES  CODE 


Original 

Test  1 

Test  2 

Test  3 

Test  4 

LINK4 

S3 

42 

26 

26 

26 

1NFUT4 

232 

139 

108 

91 

91 

OALAG 

158 

125 

— 

— 

— 

SFEXT 

193 

143 

129 

118 

89 

OAUPR 

81 

56 

52 

— 

— 

SOABB 

22 

23 

23 

— 

— 

SNXNZ 

101 

42 

37 

37 

37 

TOTAL 

840 

570 

375 

272 

243 

REDUCTION 

OS 

32S 

sss 

68S 

71S 

Comparison  of  FORTRAN  Code 
produced  by  various  LINK4  FCF  Test  Cases 
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C3NS  TA.'ns 
ST  ANOAiJO 

CiNT'S^Tf^SRAVITT  » ZC.  /•  X 'AC  ’/ 

Hi  UInJ  AXIS  • 1.  /•  ><0R.AALLT  ItfAUc:  IS  1 •/ 

iRoss.-eiGHT  • ju’CJO.: 

lNC»l^eNT.AOO«0.rO_'‘Oi3IL.rE.»P£RAfUR£  • .5 
USt  ALfA  is  ThUUST^A.'AO  iRAG  .CACCULA  T IONS 
SrANOAHo’cLr.'ASS.TolTJ  sf  _.«AACM 

LlMXA 

constants 

OISTANC£.T«0«.VAN6_l.eAOING.JOGJ  .TO.naC  • JR. 5 /•  AT  •/ 

7*  THE  fOLLOUING  j'cONSTANTS  ARE  NEEOEO  ONUT  If  UPWASN  •/ 
/•  OR  PITCH  RATE  CORRECTIONS  APE  8E1NG  “ACE  ♦/ 

ALfA_CONVERCtNCE_CRITeRION  « ,C01!  /»  5aO  */ 

alt A^I TERATION.LIHI T • 1C 
CL  CONVARGEMCe'cRITERION  • .02 
CLllTERATION.ur.NIT  ■ 15 

LOAD  fACTOR_OATA  SOURCE  • CC  AC CELEROHE TIP 

REfERINCC  ACCELtRATICN  OUE  To'gRAVITT  ■ 32.Wt*5  /*  fT/S£C?  •/ 

/•  NOPNALLT,  52.:7tC5  •/ 

THE TA_EXPONEN T • C.5  /•  NORNALLT,  C.5  IS  USED  •/ 

ALfA  NON  CCNVERGENCS  • U S S_L A S T_V A LU E 
CL  NON  convergence  • RECOMPUTE 


fT/SEC?  •/ 
52.:7tC5  •/ 


/♦  fT  •/ 

! • lx 


TMI TA_EXPONEN T • C.5  /•  nORnalLT,  C.5  IS  USED  •/ 

ALfA  NON  CCNVERGENCS  • U S S_L A S T_V A LU E 

CL_N0N_C0NVERG£NCE  • RECOMPUTE 

reconpute.cl  /♦  optional  »/ 

CONPUTE_CO  /•  optional  •/ 

angle. Of  _AfTACi: 
corrections 
otnanic.lag 

VANE*ACC£LEROMf  TER.SYSTE.A 
f REOUEnCT 
CCNPUTE 

CONS  TANTS 

characteristic. AR£A_Of .SOON  ■ .5  /♦  fT  •/ 

HOPENT.Of .IMERTIA.Of _VAN£_ACCElESO~E TER  • lx 
DAMPENING. RATIO* 

COMPUTE 

constants 

ALfA  CONVERGENCE. CR I TER  ION  • .CQ12  /*  RAO  •/ 

ALfA“lIERAIION. LIMIT  • 12 

NUHflER.Of .PO I. NTS. REQUIRED. TO .MEET. CONVERGE  ACE, CRITERION 

•85  /•  X 

characteristic. AREA. Of. VANE  • .115  /"  fI2  •/ 

OCL  OVER  OALFA“fOR_VANE  • 15. J3  /•  PER  PAD  •/ 

GAIN.CONSTANT  ^ 1 .25 

distance  fRON  VANE  CG.TO  V A N E _A £ RC OY N A H I C .C£  * T E R • 

.Cl  5*/*  f T •/ 

POOH  RENDING 
YES 

constants 

OCL. OVER. DALfA.fOR. BOON  • 15. 3A  /•  PER  RAO  •/ 

W£ IGHT.Of .aOOM*«  17. 5C  /♦  Ld  •/ 

fUMCTION.Of  fORCE.ON.AOOM 

curveI.numser  Fco* 

PITCH  RATE 
YES 
UPLASH 

flJNCTtON.Of  ALfA 

CURVe'numHER  SOIL 

LOAD .f  AC  TORS 

constants 

data. SOURCE  • 2 

CG.ACC  ELEROME  TsR  .•  I S AL  I GN'EN  T .ANGLE  » *.C  /♦  RAi,I*Sf  •/ 

ROOM  .ACCELcRGME  TE  sal  IGN 'EnT  .ANGL  £ • C.C.  aaoIANS  •/ 

ADO  I T IO.NAL  3inPU  TS 

2t  :a,  ‘.-.AMAI  • T'.O*  ' , 

.•,A*A<'  THREE') 
aDOI TIONAL.OL’PUTS 

delta,  :«ta,  o^fGA 


/ ♦ R A I,  I A S f • / 

• A A 0 : A N s • / 


Figure  B-2 
INPUTS  FOR  TEST 
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CONSTANTS 

STANDARD 

CENTER_0F_6RAVITY  ■ 20. 

NZ^WIND.AXIS  ■ 1. 

GROSS  WEIGHT  * 20000.2 

INCREMENT  ADDED  TO  MODEL  TEMPERATURE 


/* 

/* 


X MAC  */ 
NORMALLY 


DEFAULT  IS  1 */ 


/*  DEG  K */ 


USE_ALFA_IN_THRUST_AND_ORAG_CALCULATIONS 

standardIclimss.toItest.mach 

LINIC4 

CONSTANTS 

OISTANCE_FROM_VANE_LEADING_EDGE_TO_MAC  a 38.5  /*  FT 

7*  THE  FOLLOWING  2 CONSTANTS  ARE  NEEDED  ONLY  IF  UPWASH 
/*  OR  PITCH  RATE  CORRECTIONS  ARE  BEING  MADE  */ 

ALFA  CONVERGENCE  CRITERION  » .0015  /*  RAO  */ 

alfa“iteration  limit  a 10 

CL  CONVERGENCE. CRITERION  » .02 
Cl“ITERATI0N  limit  a 15 

LOAD  FACTOR  DATA  SOURCE  a CG_AC CELEROME TER 

R£F€i?flY€S -ACCELERATION  DUE  TO  GRAVITY  a 32.174G5  /*  FT/SEC2  */ 

/*  NORMALLY,  32.174G5  */ 

THETA  EXPONENT  a 0.5  /*  NORMALLY,  0.5  IS  USED  */ 

ALFA.NON.CONVERGENCE  » USE.LAST.VALUE 
CL  NON  CONVERGENCE  » TERMINATE 

RECOMPUTE.CL  /*  OPTIONAL  */ 

COMPUTE.CD  /*  OPTIONAL  */ 

ANGLE.OF.ATTACK  (ALFA) 

CORRECTIONS 

OYNAMIC.LAG 

NO 

BOOM  BENDING 
NO 

PITCH.RATE 

N0“ 

UPWASH 

NO 

LOAD. FACTORS 
CONSTANTS 

DATA  SOURCE  > 2 


CG  ACCELEROMETER  NISALIGNMENT.ANGLE  » c. 
BOOM.ACCELEROMETER.M IS ALIGNMENT .ANGLE  « 

aooitional“inputs 

BETA,  “gAMAC  TWO'), 

GAMAC  THREE') 

AODITIONAL.OUTPUTS 

DELTA,  ZETA,  OMEGA 


0 

0.0 


/* 


RAD  IANS 
RADIANS 


*/ 

*/ 


Figure  B-3 

INPUTS  FOR  TEST  4 
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B.3  DESIGN  OF  ADDITIONAL  TEST  CASES 


In  addition  to  the  performance  of  actual  FLTOPS  runs  with  the  emulator, 
some  other  work  was  done  to  enhance  the  repertory  of  test  cases.  The  Initial 
validation  effort  produced  a number  of  tests  which  proved  to  be  incomplete, 
primarily  because  of  new  capabilities  added  throughout  the  validation  effort. 
In  addition,  those  capabilities  recently  added  were  not  subject  to  the  same 
level  of  testing  as  those  identified  in  the  original  specification.  With 
these  test  cases,  it  was  possible  to  more  completely  verify  the  functional 
soundness  of  the  design  specification,  as  well  as  provide  an  initial  framework 
for  verification  testing  of  an  implemented  system. 

Figures  B-4  through  B-8  exhibit  the  test  cases  as  instructed  by  this 
effort.  Note  that  only  one  test.  Figure  B-4,  is  completely  new.  The  others 
are  merely  modified  versions  of  the  originals  constructed  as  a part  of  the 
initial  validation  effort.  (See  Appendix  A.)  A brief  explanation  of  each 
of  the  test  cases  follows. 

The  test  of  the  EXECUTE  and  PARAMETERS  statement  capability  was 
not  previously  constructed.  Shown  in  figure  B-4,  this  test  proved  to  be 
significant  in  uncovering  some  logical  flaws  in  the  original  design. 

Using  two  execute  modules,  SQUARE  and  AVERAGE,  the  test  exercises  both 
the  setup  and  passing  of  parameters.  Both  real  and  integer  values  are 
passed  and  calculated.  This  test  does  not  exercise  the  special  FORTRAN 
format  switches  provided  in  the  design  for  control  of  the  data  conversion 
in  executable  modules.  Being  of  a quick  and  dirty  design,  the  emulator 
uses  the  PL/1  default  conversion  rules  for  these  conversions. 

Figure  B-5  lists  an  enhanced  INPUT  statements  test.  An  important 
addition  to  the  design  was  the  capability  to  read  catenated  inputs.  Only 
minimally  tested  in  the  previous  version,  this  test  now  provides  an 
expanded  test  capability  in  this  area.  Specifically,  the  test 
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ItSSAGECGNrSTAKT  OF  EXECUTE  'ROUTINE  TEST*) 

FINI)(INT£RP0LATI0N_R0UTIN£  .TtPLE_IVFO'^'--ATIOFv.04TA)  ri'oOR:  IG  * '<  3 
flcFINE  X(1G),  Y(5)~ 

ImPUT('=')  ERROR:  DO  e\D 
SET (1=  1) 

DO  WHILE  I < in 
INCRE'IfNTC  I ) 

INPUT (CONSTANT)  ERROR:  PO  END 
ENTtR(X(I),*) 

FNO 

INPUTCEND  OF  NODE*)  ERROR:  PO  END 

INPUT (' INTERPOLATION  VALUES'  '=')  ERPOR:  PO  fVD 

SET(I=^) 

DO  WHILE  I < 5 

INPUT (CONSTANT  OR  *,*  CONSTANT)  ERROR:  DO  END 
INCRE'IENTC  I ) 

FNTER(Y(I),*) 

END 

STATUS( 'CONTENTS  CF  SYiTBOL  TAPLES  BEFORE  PFC.ir:  OF  FXEClITt') 

ser(>iAx  = in) 

PARAMETERS  SO U A R E ( R E AL  , R E A L ) 

parameters  average (REAL, integer, real  (PAX)) 

MESSAGE  ('G\:PARA'''ETEPS  IDEnTI  FTEP — EXE  CUTE  ' ) 

EXECUTE  AVERAGE (AVGX, MAX, X ( 1)  ) 

-•bSS  AGE  ( • G\ :VALUE  OF  AVGX  = ',AV6X  =>  FIT. A) 
cXtCUTE  Sa'JARE(AVGX,AVGX?) 

MESSAGE  ( 'GN:VALUE  OF  AVGX  SCLIARED  = ',AVCv,?  =>  F10.A) 

STATUS( 'SYMBOL  TABLES  AFTER  AVERAGE  AMi  SuUARL  tXEfUTt:  ') 
P.',RA.METERS(REAL,INTEGeR,REAL(5)) 

EXECUTE  AVERAGE(AVbY,5,Y(1)) 
tXECUTE  SQUARE (AVGY,AVGY2) 

STATUS( 'CONTENTS  OF  SYMBOL  TABLES  AFTER  Y USfP  IN  EXFCi'Tf') 
EXECUTE  SaUAR£(7.3*5.4,SQR) 

MESSAGE ( 'GN: ANSWER  SHOULD  Bt  1553.04  ',SQk  =>  F1P.?) 

EXECUTE  AV£RAGE(AVGPX,5,X(A)) 

MESSAGE  ( 'G\:AVERAGE  OF  LAST  5 VALUES  IN  X ',AVCPX  =>  FK'.?) 

/•  END  OF  EXECUTE  TEST  •/ 


Figure  B-4 
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■■>£SSAGt(’GS:8t(iI'.f  I'iC  3f  I'^OoT  ST*Tc.“S  .T  TtST') 

/•  TcSr  r.PL'I  STAT£*e.'.T  ./ 
f r.D<COf4STANTS>  /•  POSTTlD'l  FlLc  •/ 

:.“ut<'6nu  of  ngce')  /•  fcfcf  rc  ».£a7  rent  •/ 

rvPUT(»3S0)  ESHoR:  .■•£$$•&=( 'G- rCCl'Ll  'CT  FI>?  .OS'") 

t^TE»(;'>PuT,•) 

r.“UI('»')  EPPCS:  30  EN3 

:':PUT<  .OMOER)  ERROR:  30  F«.n 

E 4TE.j(  J,.) 

F !SD(  INTERPOL  A riON_ROUTI*Jt  ) 

!‘lPllT(’»'  OR  .40R0)  "error  : r ESS  A G E ( ' GW  : 3 I 1)  \C.T  FIND  »•) 

I..?0T(C0’(STANT  or  RORP  or  STRI'JG)  ERo"R:  PESI'CE 
(G,'.:OIO  NOT  FIND  POLY*) 

F liDTSTRlNG)  ERROR:  00  ERO 

I''PUT(STRING) 

t\TER(  iNPlJT, STRING,*) 

INPLTCENC  of  >.0C£')  ERROR:  DO  E\C 
r'<>UT<4CR0)  ERROR:  CO  END 
IF  • • ' SIGME0_NUr9£R  ' THE'’  00 
/*  JROER  PURPOSELY  .RONS  •/ 

ENTER!  INPlJT,SICNE0_NU4'*Sf  R) 

INPUT(SIGNeO_Nli.'l&ER) 
error:  if  INPUT!***)  THEN  rNPUT!Uri-0) 

ERROR:  INPJTtSIGMEO  NU>ntF) 

ERROR:  , 'MESSAGE!  *6A:ThIS  .'ESSAGE  ScruLO  ?E  PP!*TEO*) 

ELSeMESSAGE!  •G'.:DI0  NOT  FIMO  THE  * SIGN') 

ENTER!? ,*) 

END 

/•  NOg  input  catenated  input,  I,E.  ‘N  INPUT  GROUP  ♦/ 

F I ND ! INTER POLaTT ON _ROU tine. interpolation .VALUES) 

SAVE.PCInTE.o 

INPUT!  *»*  “UNcER  *,'  NUPltR)  ERROR:  PO  EN'O 

restore  pointer 

INPUT!  •*•  NUPJER  *,*  weSO) 

ERROR:  .NESSACEt*GN:THlS  -‘ESSAGE  ShCULO  NOT  EE  RRI-TE!') 

/•  NO.  INPUT  special  SYYOCLS  ♦/ 

F i'.CfiPECI ‘L.SY-iBCLS)  ERROR:  DO  £f:D 
EMER!!NPuT,*) 

Oo  .pile  INPUT!**'  OR  *♦'  OR  '-'  CF  ','  CP  '!'  OP  ')'  ) 

CArE.'.'»TE!3,  •) 

END 

I'.PUT!*EN0  of  node*)  error  r^ESSAGE  ( 'G,  ;EF.L  CF  r.OCE  VAE'.T  FEAD') 

I'PUTI.'ORO)  ERROR;  00  END 

E-.TER!r!PUl,*) 

INPUT!***)  ERROR;  CO  END 

NESSAGE  ! *GN:START  READING  1'.  ‘PITHPETIC  EXPPESSIC*") 

I'VOrt  A.EYPR 

F t.NDlPO.INPUT.TEST  .SPECI  AL.5Y'".-0l:  ) 
input  !.NUr'Sc«  ) " 

Error:  i.nputircro) 

ERROR:  I NPU T ! S TS I MG ) 

SETfSTRI.NG  « *) 

SET  !Cn»RACTER  * SUfSTR  ING!STRlr.G,S,1 ) ) 

SET!!  • c) 

Dm  for  Each  sua.noce  of  i 

INCRE/EnT! I ) 

IF  INPUT!W0P0  '*'  OR  ROPD  '*'  f S .C'C  ')')  THE' 

IF  CHAR  » * THEN  MESSAGE  I ' SI- :Fci  • D ci-f-icrf-, 

ELSE  ‘■ESSAGE!  '(.-1:3  4C  OF  TEST  Crf-"tT£FS  fOUr".  rir'ii't  '.I*-*!' 
cLGt  'ESSAGE! 'G'l  :NG  'aTCp,  THAR'CTF-  :u'‘'TF  '.IaRD 

END 

•’iSSAGe! 'G:N:Ef.3  OF  INPUT  ST'TC'E'.T  TEST*) 
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Includes  not  only  the  reading  of  the  Input  groups  but  also  this  capabil- 
ity combined  in  an  OR  construct.  Note  also  that  a11  message  statements 
have  been  changed  to  Include  the  type  Identifier  in  the  first  parameter. 
This  consolidation  not  only  simplifies  the  format  of  the  statement  but  also 
allows  for  error  messages  to  be  referenced  as  table  entries.  The  SAVE_ 
POINTER  and  RESTORE_POINTER  statements  are  also  included  in  this  test. 

An  expanded  version  of  the  OUTPUT  statement  test  is  listed  in 
figure  B-6.  Exercised  quite  extensively  in  the  actual  execution  of  the 
LINK4  FCF,  the  OUTPUT  capability  was  not  tested  thoroughly  in  the  origi- 
nal test.  This  test  has  been  upgraded  to  correct  this  and  provide  an  inde- 
pendent, fast  test  of  the  more  explicit  output  functions.  Included  are 
uses  of  the  end  of  record  and  end  of  file  and  formatting  capabilities. 

In  addition,  tests  of  double  and  triple  substitutions  during  pass  1 
and  pass  2 are  used.  Synthesized  as  well  as  modified  FORTRAN  statements 
are  also  output.  Several  FORMAT  statements  are  included  which  use  many 
variations  of  legal  FORTRAN  formats  as  a test  of  the  format  lexical 
analyzer. 

Figure  B-7  lists  additional  enhancements  to  the  symbol  table  mani- 
pulation capability.  Specifically,  changes  were  made  to  test  the  equiva- 
lencingof  symbol  table  names  using  the  DEFINE  statement.  Changes  made 
to  the  REPLACE  statement  were  also  included  in  the  test.  The  DEFINE 
statement  tests  includes  chaining,  nullifying  and  re-equivalencing  to 
test  the  various  functions  of  the  statement.  In  addition,  both  array  and 
regular  symbol  tables  are  included  in  the  test.  The  REPLACE  statement 
uses  both  global  and  a specified  number  of  replaces.  Also  included  was 
the  use  of  DEFAULT  to  reference  the  default  symbol  table. 

The  FIND  statement  test.  Figure  B-8,  was  modified  to  check  out  the 
redefined  operation  of  the  FIND  instruction,  notably  that  the  input  pointer 
is  only  repositioned  if  the  identified  node  is  actually  found.  Note  that 
tests  identifying  both  conditions  are  made. 


w /•  TEST  Cf  fO?T?Af.  OUTPUT  •/ 

WSlTed.UiO)  INPUT 
1.^0  T',R  •»TUCa2///) 

IKN.EU.S)  30  TO  7 
c this  is  in  in  line  CO-'H.EVT 

il'CNSICN  A(17,i) 

15  X • SSRT<7.3«i;.)'»(7./S*T«<) 

*(3,S)  » IXPCA(1,2>)*5.*7-J. 

£‘.TE»{»ASS1,XJPUT,'(<J)*) 

P S£T(N  » 7.i«l4.*5.) 

P /•  N AS  OI^ENSION  SHOULD  SE  D*’  '/ 

P £NTEa(PASS1,XJ,'*N'> 

P e'lTeP{PASS2,*N,VALUE(N)»>I ) 

XAJBUf  « TAJHUf  • 5. 

E&UIVALENCEIJPUF («J ),I0) 

<E^0  ■ 7.3  * X(*J) 

1 ♦ 2.9  • X(1> 

P 0cLETE(PA3S1,AJUUF) 

P DeLETEIPASSI ,*J J 

P /•  \0H  synthesize  a STATEvp.'T  •/ 

» OUTPUT(»25  CONTINUE*, P) 

P OuTPuTCIf  (Y.EO.C.)  CALL  SUOe  ( J , X ) • , - ) 

? OUTPUT! 'lure* ) 

P OUTPUT! 'FORHATt I5,G1 4.7,3 (3x,n 0.4/ ))', A) 

P E..TEa!OUT  TAP,STATEHE*iT,*IF!J.GE.7)  X«7.;»Z*) 

P CUTPUT!*75*,'/ALUE!0UT  T A 3 , S TA  TE>*£N  T ) , t ) 

o 0UT?UT!C0,-1»£NT;,*  THIS  IS  A GENERATED  COPH  E’.  T • , i< ) 

P SeTCOUTPUT  » 'DATA') 

P 0UTPuTCC0L!*),7.  • F ORH A T ! F 5 .21 , COL ! 21) , ! T . ?♦ A . 5 ) *3 . FO A r i T ( I ) , . ) 

P OUTPuKEND  of  RECORD) 

P OUlPUT!COHPENT:, • GENERATED  S TA TEYEMT * , *) 

P .1llTPUT!C:,C0L!1C  ),VALUE!0UT_TA6,STAT£f  rNT)»>A17,  ••♦«  ',  -) 

P OUTPUT!!:, •— PREVIOUS  CO’NF.NT  SHOULD  END  1. 1 Th  •.*••,») 

P /•  TEST  automatic  output  OF  PUFFEP  CN  ECR  •/ 

P OUTPUT!  •1l'rCC0NTINUE*,E0R> 

O P)TPUT!C:,'- -PREVIOUS  CARD  SHOULD  TF  INCC'"R£CT  FTN,  ClTFl.T  *S 

P 0jTPoT!10.3*«.5*3d.i«!7.4-1  .2)  ■>  I,CCL!*r),N  F OP- A T ! F 1 .5  ) , F r f ) 

e SETIOUTPUT  ■ 'FCRIPAN') 

1i'  X ■ ? ♦ : 

C-  — — — — ijExT  FORTRAN  IS  CCPPLICATEO  FCKFAT  STATE-EVT 

2C:  •.  fORHAT!ir,A,//17!FV:.'>,3!5x,G14.7,l7,5M31,5KTFST1/»e7,t,2L1'  )) 

C STaTE.vENT  alTH  several  pretty  CCITINUATIOf  CARDS 

DATA  A/  7.30,  15.62,  17.32,  24.50,  7F.p:, 

1 P7. 33, 1 22. 6.),  14. *5, 3??. 21,  *9.!P. 

2 39. ;0,  23.44,673.96,  3.54,  62. i 4, 

3 Y4.A5,P05.74,i>C5.io,  34.98,  7A.(:«/ 

01  •CHS  ION  ’ ! VN)  ,X  !2,*N)  ,AR«  A!1  5)  ,L  !»t.,i'N) 

P MESSAGE  I 'LNiENO  OF  OUTPUT  TEST*) 
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rSLf.TiC  :) 

ITII-IISC'J  4»Te?  CELCTe  • .'’“.r*  ■ ,' ) 

S4TC.«'T**Ls 

SE^^C  OU  £\  Tf  Y • ) 
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SETC*) 
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SETCI  ■ (7.J-2.7>»»2) 
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SItCA  • 'N*) 
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SST<9  • 'A') 

SETCVACUCCFALUtCC))) 

tSTi»(3,C) 

STATUS!  •SY.'A_T»t  AFTEP  JCCHLS  INCIPECT  $ E T • , SY^^TA*  ) 

E.'CO 

SETCIal) 

90  while  I<«5 
rNCRCTEVTCI) 

EN9 

STATUS! 'value  of  I AFTEP  I ?;  CPE  AEN  T • . FL  TO  PS  , I ) 

O.T  while  IP'’ 

OBCPE.TEnTCI) 

ENO 

STATUS! 'VALUE  OF  1 .AFTS.P  OE  CPE  aEST  ' , FL  yCPS  , I > 

/»  TEST  OF  OEFnE/EOUIVALE!!CE  STATE  'ENT  »/ 

9EFI.NE  SYapoLSIT) 

FtNOCeO  I'YPUT.TEST.SPECIAL.SY-'POLS) 

SST!I«0> 

OH  FOP  EACH  SUP.NOOE  OF  3 
INP'JTCWORO) 

INPUT!'*'  CP  OP  CP  '!'  OP  •)'  C»  '/'  C»  '•••) 

XNCPE'»SNT(I) 

•NTEPtSYHPflLSd)  ,•> 

ENO 

STATUS! 'SYP90LS  AFTEP  INPUT  CC-PLE  T E * , » Y * ? .TLI  > 
define  special  as  SYrPOLS 

STATUS! 'SPECIAL  OEFINEO  AS  SY^'TOLS  ' ,SP  t C I AL ) 

E‘|T£P!;psc:al!2),  '>') 

E’TEPCSPBCIALCS), '<') 

STATUSC'SPECIAL  aftep  ’ .•!5  5 '06IF  lEC ', SPECIAL) 

CEFISi  T«ALC  as  special 

ST*TU$!'0UTPOT  OF  TAPLS,  SECO'O  ITE*  r Cw A 1 * • , T *« L ' ) 

OEFINE  SPECIAL  AS  NULL 

ASSERT  TaELI  eTPTYlTAeLE)  £PPC»:  •■•£  £S*i>t  ! 'fiW  : T an  lE  nC  T £rwTY*) 

pefine  new  as  SY-**0LS 

$TITUS!'NE«  TaALE  NANE  A *5 1 CSE 0 • . S E . ) 

CaTENATE!.n£j!2>,'«') 

CATENATSC'iEw!  $),'•') 

STaTu$('nE.v  AFTE*  2 Af.O  5 'OOIFIEO ',;.£  ) 
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.*1E:SSAGE('GN:B£GISMNG  OF  FIND  TEST') 

/*  TEST  OF  INPUT  FILE  SEAPCH  — FINL*  */ 

FIND (GEOPHYSICAL  M00EL.EARTH.N0N_R0TATING) 

ERROR:  f*ESSAG6<  ' SW  :CANNOT  FIL’D  6£  OPHY  S I C A L.NODEL  , tT  AL') 
FINO(GEOPHYSICAL_MOOEL)  ERROR:  DO  END 
F1ND(«. EARTH)  ERROR;  DO  END 
FINO(i).NON_ROTATIN6)  ERROR:  DO  END 
FINOdNTERPOLATION.ROUTINE)  ERROR:  DO  END 
SAVE  POINTER 

FIN0(3.TABLE_INF0RMATI0N.DATA)  ERROR: 

MESSAGE ( 'GArCOULD  NOT  FIND  TABLE  DATA') 

RcSTORE.POINTEH 

/*  NOW  FIND  A BROTHER  NODE  •/ 

F1LD(S. INTERPOL  AT  ION.  VALUES) 

ERROR:  MtSSAGEC 'GWrIMPROPER  FIND  FUMCTICL') 

/*  FAILURE  TO  FIND  SPECIFIC  NODE  — TA<E  ERROR  PAT'^  */ 
FINO(&£OPHYSICAL_MOOEL.VeNUS.cLLIFSE  ) 

ERROR:  MESS  AGE  (•  GN  :NODE  F'OT  FOUND  — PLANNED  ERROR') 
FINDCGEOPHYSICAL.MODEL) 

FI ND(i. EARTH. SPHERE  CAL. NEXT  LE VE L . ANOTPE R_LE VED 

ERROR:  MESSA&e( 'GN-.THIS  MESSAGE  SHPLLD''eE  PRINTED') 

IF  not  FINC(ii. earth. SPHERICAL)  THEN 

NESSAGE( •GV:IMPR0PER  OPERATION  Of  FI\P') 

/*  test  assert  error  BRANCH  */ 

ASSERT  NOOE_EXlSTS(REQUIRED_CO''*PUTATIf'NS  .EKE  PG  Y.t-iE  IGH''’ ) 

ERROR:  DO  ~ 

F1NO(REQUIREO_COMPUTATIONS.ENERG Y_HEIGHT) 

ERROR:  MES  S AGE  ( • G V : ENE  RG  Y_H  E I GH  T VOCE  NOT  FCl'f’D') 
MESSAGE  ( 'GN  :ASSERTION  FALSE  — C?  EPGY.WE  IGHT  NOT  FOl-f.r') 
END 

/*  SCAN  PAST  COMPLICATED  ERROR  ASSERTION  ♦/ 

ASSERT  NOT  FlNO(REQUIREO_CO»'PUTATICNS.ENERGY_WEIGHT ) 

ERROR:  DO  FOR  EACH  SUBNOOE  OF  CONSTANTS 
INPUT(WORO  CO»'STANT) 

ERROR;  DO  WHILE  I NPUT  ( C CHS  TA  f.  T ) 
ENTER(FLTOPS,*,*) 

I F INPUT!  • , • ) THEN  DO  ENC 
END 


END 

MESSAGE! •GN:END  OF  FIND  STATEMENT  TEST') 


Figure  B-8 
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The  appearance  of  ASSERT,  STATUS  and  MESSAGE  conmands  throughout 
these  tests  have  been  increased  as  a method  of  testing  the  internal  de- 
bugging capabilities  of  the  precompiler.  Extensive  uses  of  these  Capa- 
bilities have  proved  worthwhile  even  in  the  development  of  the  test 
cases  themselves. 

B.4  DESIGN  CHANGES 

There  have  been  several  design  changes  that  have  resulted  from  the 
extended  validation  effort.  Figure  B-9  lists  these  changes.  Most 
notably,  execution  of  the  EXECUTE  statement  test  identified  several  linking 
errors  that  existed  between  primitives  and  rules  as  identified  in  the 
original  design.  Specifically,  some  additional  bookkeeping  operations  were 
necessary  to  insure  that  proper  accounting  was  done  on  the  addresses  of 
parameters  passed  into  an  execute  routine.  In  addition,  the  use  of  the 
ARRAY-ELEMENTS  rule  was  somewhat  altered  to  insure  an  unambiguous  use  of 
array  structures  when  defining  and  using  array  tables. 

Another  significant  change  was  the  identification  of  the  need  for 
modifying  the  basic  operation  of  the  FIND  connand.  Although  adequate  as 
originally  conceived,  it  was  discovered  that  programmer  errors  could  be 
reduced  and  programmer  acceptance  commensurately  increased  by  slightly 
altering  its  operation.  Instead  of  always  moving  the  input  pointer  in 
search  of  the  olace  indicated  by  the  command,  the  precompiler  now  alters  the 
input  pointer  position  only  if  the  FIND  was  successfully  executed. 

This  insures  that  the  programner  always  knows  the  pointer  position  and 
enables  him  to  considerably  simplify  input  file  searches. 

Still  another  change  made  was  the  addition  of  a capability  to 
access  the  default  symbol  table  by  using  the  key  word  DEFAULT.  Useable 
from  several  statements  such  as  REPLACE  and  CATENATE,  this  affords  access 
to  the  default  symbol  table  from  most  symbol  table  operations.  The  single 
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exception  is  the  CLEAR-TABLE  command.  By  using  the  key  word  DEFAULT 
in  the  table  name  position,  the  user  can  indirectly  reference  entries. 

Note  that  DEFAULT  cannot  refer  to  an  array  table,  and,  as  a result, 
cannot  be  a subscripted  entity. 

It  was  found  that  a change  in  the  definition  of  an  FCF  identifier 
was  needed  to  decrease  probability  of  user  errors.  In  the  design,  the  # can 
be  used  In  the  In-line  FORTRAN  code  as  a placeholder  for  eventual  sub- 
stitution. The  need  for  the  capability  of  having  symbol  entries  in  the 
PASS1  and  PASS2  symbol  tables  with  the  # as  the  first  character  became 
clear.  Although  the  ability  to  enter  these  symbol  names  as  strings 
was  a part  of  the  original  design,  a preponderance  of  user  errors  resulted 
in  the  test  FCF's  because  of  a natural  bent  to  leave  off  the  string  de- 
limiters. The  obvious  solution  was  to  allow  identifiers  to  begin  with 
■^■he  # by  itself  is  not  an  identifier,  but  is  still  a special  symbol. 

The  DO  FOR  EACH  SUBNODE  statement  was  also  found  to  not  operate 
properly  when  they  were  nested.  A change  w'as  employed  which  effectively 
does  an  implied  save  and  restore  input  pointer  at  the  time  the  loop  is 
begun.  Thus,  after  the  input  pointer  is  positioned  at  the  proper  place, 
i.e.,  the  node  for  which  each  subnode  is  to  be  processed,  the  input 
pointer  is  saved.  At  the  completion  of  the  activity  on  the  last  subnode, 
the  input  pointer  is  repositioned  to  the  saved  location. 


■wwggggBPWiiiWJtMJi ,11  I nil,  i!  I „ , ,1  . 


DESIGN  ADDITION/CHANGE  RESULT 


Add  ARITH-DEPTH-COUNTER  variable  to  sev- 
eral rules. 

Allows  for  proper  parameter  location 
bookkeeping  for  EXECUTE  statements 

Modify  function  of  ARRAY-ELEMENTS  rule 

Allows  for  proper  evaluation  of  sub- 
scripts when  used  to  identify  array 
bounds  and  array  position  1 

Add  DEFAULT  key  word 

Allows  all  symbol  table  operations  ex-  ! 
cept  CLEAR-TABLE  to  reference  the  | 
default  symbol  table  indirectly 

Alter  operation  of  FIND  statement 

Only  successful  FIND  operations  re- 
position input  pointer.  User  never 
loses  track  of  input  pointer  position 

Modify  definition  of  an  identifier  in 
the  FCF 

A # followed  by  at  least  one  alpha- 
numeric character  can  be  an  identifier, 
resulting  in  fewer  FCF  syntax  errors 

alter  syntax  and  function  of  REPLACE 
statement 

REPLACE  does  a global  replace  of  identi- 
fied string.  Optionally,  the  user  can 
specify  a 5th  parameter  giving  a number 
of  replaces 

Allow  nesting  of  DO  FOR  EACH  SUBNOOE  OF 
rules 

The  user  can  now  nest  DO  FOR  EACH  state- 
ments to  an  arbitrary  depth.  Input 
pointer  repositioned  to  location  at 
start  of  loop  after  last  subnode 

RULES  ADDED:  NONE 

RULES  MODIFIED:  FIND_STATEMENT,  DO_FOR_EACH,  STATUS_STATEMENT , DELETE_STATEMENT,  ARRAY 
ELEMENTS, DEFINE_STATEMENT,  INDEX_FUNCTION,  LENGTH_FUNCTION,  MESSAGE_ 
STATEMENT,  PARAMETERSJTATEMENT,  EXECUTE_STATEMENT,  LOCATION_POINTER, 
INDIRECT__LOCATION_POINTER,  ALL  ARITHMETIC  EXPRESSION  RULES, 

PRIMITIVES  ADDED:  NONE 
PRIMITIVES  MODIFIED:  .REPLACE 


T 


' 


Figure  B-9 

FLTOPS  DESIGN  CHANGES 
Extended  Validation  Effort 


APPENDIX  C 

LINK4  FCF  AND  TEST  RESULTS 


Appendix  B describes  the  FCF  that  was  coded  by  AFFTC  personnel  to 
customize  the  UFTAS  LINK4  program.  This  FCF  was  executed  through 
the  FLTOPS  emulator  with  four  FLTOPS  INPUT  files  for  testing.  The 
following  pages  contain  listings  of  the  FCF,  figure  C-1,  and  the 
results  of  Test  4,  figure  C-2.  See  figure  B-3,  page  B-11,  for  a 
listing  of  the  Test  4 INPUT  file. 


C-1 


/•*•*•*  UflAS  L1MK4  FCf 


HAIN’t  /*  UFIAS  DRIVER  •/ 

If  NCOE.EXISTS  fCONSTANTS*S1ANOARD« 

USE.ALfA.lN.THRUST.ANO.ORAe.CALCULATtCNSI  '1MEIF 
ENTER  fUFTAS* THRUST* 'YES • I 
ELSE  ENTERCUfTAS*1MRUST»«NO*l 
INVOKE  LINK4 
END 


Figure  C-1 
FCF  FOR  LINK4 
(page  1 of  41) 
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L1NK4t  /*  LINK4  SE1UP  *! 


00  FOR  ^YFBOL  TABIE  ilNB4 
INVOKE  LINK4.IKI11AI 
IF  OAW  <>  'NC*  THEN  OC 
INVOKE  L1NK4B 
INVOKE  JNFUT4B 
INVOKE  OALAC 
END 

ELSE  DC 

INVOKE  LINK4A 
INVOKE  INPU14 
END 

INVOKE  SFEXT 

IF  DAU  <>  •N0«  OR  DAO  <>  •NC*  THEN  INVOKE  OAIPR 
IF  DABB  <>  'NO*  THEN  INVOKE  OABB 
INVOKE  SNXNZ 
ENC 

STATUSf^LTNK4  SYNBOL  TABLE**  11NK4) 

STATUS(«FASS1  SYNBOL  TABLE'vPASSl) 

/•  CLEAR  TABLES  «/ 

CLEAR.TABLE(LINK4} 

0ELETE(PASSl»iL01Nt 

OELETE(PASSl>iLOBlF) 

DCLETEfFASSlvfLOOiTI 

OELETE(PASSl»fIBUF) 

OELETEfFASSl»IIDlF) 

DELETE(PASSl«tC0HL4CAT I 
DELETE fFASSl9 VC ONCURVE) 

END  LINK4 


Figur#  C-1 
FCF  FOR  LINK4 
(page  2 of  41) 


L1NK4.1K1TIAII 


i*  LINK4  IHlllkLlimth  */ 


f*  READ  INRUl  EER  LINK4  AND  SETtP  INTERNAL  FLAES  AND  SYMBOLS  «/ 


/*  CHECK  FOR  ERRORS  */ 
F*  SETUP  CCMMON  BLOCKS  «/ 
/•  CREATE  DEFAULT  XNITILIIATION  STATEMENTS  */ 
9*  SETUP  B-FILE  IFC  DATA  STATEMENTS  «/ 


FIND  <LINK4«  CONSTANTS) 

INVOKE  LACONTAB  /•  LINK^  CONSTANTS  TAB  «/ 

INVOKE  CON.REAO 
CLEAR.TABLEf CONST) 

FTNO  (LTNKA*  ANCL E.GF. ATTACK ) 

If  FIND  t«LOOKUP  THEN  DC  /*  ALPHA  BY  LCCKUF 

FIND  t«fUNCTION.CF 

IimOKE  FUN.REAO  F«  ALCOKUP*KFAlK»KLALF  *! 

SET  (KFALF  > KFIRST) 

SET  IKIALF  • KLAST) 

SET  fAtOOKUF  • FUN.TVP) 

SET  tDAU  • 'NO*) 

SET  (DAO  • •NO*) 

SET  (OABB  - 'NO 
SET  (DAN  - 'NO*) 

END 

ELSE  If  PINO  (S«CCRRECT10NS)  THEN 

INVOKE  ACORRECT  /•  PLFHA  BY  CCRRECTICNS  «/ 
ELSE  MESSAGE  ( I •• S* ANCLE.OF.ATTACK  NEEDS  EITHER  LCCKLP* 

»•  CR  CCRRECTICNS  SLBNCCE*) 

FTNO  (LINKA*  LOAD.F ACTORS*  CONSTANTS) 

ERROR-t  MESSAGE  (l**S«LOAD.FACTCRS  NCT  AVAiLAFLE*) 
INVOKE  LALFTAB  /A  LINKA  LGAO.FACTCR  TAB  */ 

INVOKE  CON.REAO 
CLEAR_TABLE(CONST  ) 

IF  FIND  (LINKA*AOOITlCNAL_INPUTS)  THEN  DC 
SEKNAME  ■ ’IN.PARN*) 

SET(UN7TS  • •IN.PARU*) 

INVOKE  PAR.REAO 
SEKN.IN.FAR  ■ NEAR) 

ENG 

If  FIND  (LINKA«AOOITICNAL.CUTFUTS)  THEN  CC 
SET(NAME  - •OUT.PARN*) 

SEKUNITS  • *OLT.PARU») 

INVOKE  PAR.READ 
SET(N_CUT.PAR  • NPAR) 

ENC 

'NVOKE  LAPARIC  /•  SETUP  B FILE  I/C  CCMMON  AND  DATA  STM1S  !«/ 
INVOKE  lA.CCMMON  /♦  SETUP  LINKA  CCMMCN  BLCCKS  ♦/ 

ENTER (PASSl*«LOIN«N.IN. PAR) 

ENTER (PASS1*«L0BUF»«6«*) 

ENTER (PASSl*RLOCUT*N_CUT. PAR) 

IF  UAV«**YES*  THEN  DC 

ENTER (PASSl»fIBUF»«(I)*) 

ENTER(PASS1»#ID1M*  •(fLDBUF)*  ) 

ENC 

ELSE  CO 

ENTER(PASSl»flBUF»«  *) 

ENTER(PASSl»fIOIM««*l 

ENC 

END  LINKA.INITIAI 

Figure  C-1 
FCF  FOR  LINKA 
(page  3 of  Al) 
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ACORRECT-t  /*  ALFA  10  BE  FOUND  BY  C0RREC1ICNS  1C  REASIRCO  ALFA  •/ 


SEKAtCOKUR  - •N0*l 

FIND  LINK4»AN6LE.CF.A11ACR«C0RRIC1ICNS 
SAVE.PUINIER 

FIND  ••OVNANIC.LAC  ERROR*  NESSACE  ( I*  *S  < OVNANIC.IAC  NCI  SFECIFIEOM 
INVOKE  DAW.SE1UF 
RfSiaRE_P01N1ER 
SAVf.PUlN1ER 

FIND  ••BOON.BENOINC  ERROR*  NESSACE  (!• 'S t BOOP.BENCINC  NCI  iSPElFlECM 
IF  FIND  8«NC  IHiN  $E1  (OABE  • «NC*I 
ELSE  IF  FIND  B.YES  1HEN  DC 
00  FOR  EACH  StBNOOE  OF  S 

IF  INPU1f«C0NSYANr5M  1NEN  DC 
INVOKE  L4BB1AB 
INVOKE  CON.REAO 
END 

ELSE  IF  INPU1f*FUNC1I0N_0FM  INER  OC 
INVOKE  FUN.REAO 
SE1IK0ABB  • KFIRS1) 

END 

ELSE  KES$ACEfI»«Sa  INVALID  INPU1  UNDER  BCCK.BENOIiK€«V 
END 

SEKOABB  - •VES*V 
ENO 

ELSE  NESSA€EU*«S*  BOON.BENOINC  PUS1  BE  EI1NER  "YES*  OR  "NO"**! 

SAVE.P0IN1ER 

RES10RE.PQIN1ER 

FIND  B«PI1CH_RA1E  ERRORS  NESSACE I !• *5*  PI1CF.RAYE  N01  SPECIFIEO'I 
INPUKVOROI 

IF  FIND  a«YES  OR  FIND  a«NC  1NEN  SE1I0AC  - «} 

ELSE  NESSACE (I»’*S*  UPWASN  POST  BE  EIINER  •YE«*'  CR  "NC**  ) 

SAVE.PalN1ER 

RfSiORE.POINIER 

FIND  a.UPNASH  ERRORS  NESSACE <!• •S«LPVASH  NCI  SPECIFIED*! 

IF  FIND  8»FLNC1ICN.0F  IHEN  DO 
INVOKE  FLN.REAO 
SE1  (DAU  > FCN) 

SE1  (KFDAU  • KFIRS1) 

. SE1  (KLDAU  • KLAS1I 
END 

ELSE  IF  FIND  8«N0  IHEN  SFKOAU  • <«NC*) 

ELSE  NESSACE! I*«S>INVALI0  INPU1  UNDER  UFUASN*! 

ENO  ACORRECY 


OAW.SfTVPt 


/*  OVN«niC  LAC  COmiiCTICNS  •/ 


INPUTf*ENP  Of  NCOEM 

If  INPUT  l«NO*l  TMCN  SET  fOAU  • fNCM 
ELSE  CO 

INPUTIUOROI 

If  P • «VANE.ACCELEftOPCTER.SVSTEP*  THEN 
SET  IDAW  • 'TES*) 

ELSE  If  SUBSTRINCf**  1#  41  • •«ANE*  THEN  DC 

PESSA6EfI»«N<  ILLECAl  NCOE  UNDER  DTNANIC.LAC *1 

SET  (DAN  • «TES»I 

END 

ELSE  DC 

NESSACE(I#<Nt  NC  VALID  INPUT  UNDER  DYNAPIC.L AC* *t 

SET  (DAN  • •NCM 

END 

ENC 

If  DAN  • «YES«  THEN  DC 


SAVE.EflINTER 

FIND  (a«f  REQUENCYI  ERROR*  PESSACE ( I9  •$*  FRECUENCY  NCT  SFECIFIEO'*! 
INPUT  (•END  OF  NCDEM 
IF  INPUT(«CCNPUTE*I  THEN  DC 
SET  (FREC  • 41 
INPUT  (•END  OF  NCOE*) 

INPUK  •CtNSTANTS*) 

INVOKE  L40lFTAe 
INVOKE  CCN.REAC 
END 

ELSE  DC 

SEKFREQ  • •CURVE*) 

INPUT  (•fUNCTION.DF*)  ERROR*HESSACE(  I>«S«FRE<1UENC  V ERRCR*  » 

INVOKE  FIN.REAO 

END 

PESTOPE_POINTEP 

SAVE.POINTER 

FIND  (S«OANPENIN€_RATIC) 

INPUT  ('END  OF  NODE*) 

IF  TNPUT(*CCNPUTE*)  THEN  SET  (CAPP  •«) 

ELSE  DC 

SET(OANP  • «CURVE*) 

INPUT  (* FUNCTION.CF* ) ERROR*  PESSACE( 

•IS  NO  OANPENINC.RATTC*  ) 

INVOKE  FUN. READ 
END 

RESTORE. PCINTER 

FIND  (R«CONSTAKTS)  ERROR*  PESSACE( 

'*IS  OYNANIC  LAC  CONSTANTS  NOT  SPECIFIED*! 


INVCKE  L40LTAE 
INVOKE  CON.REAO 

ENC 

END  CAN.SETUP 


Figure  C-1 
FCF  FOR  LIMK4 
(page  5 of  41) 
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CON.PCAOi  /«  CQNS1ANTS  *CAO  Rilf 

/«  CCNSTtlwlI  • «MIO  USiP  INPU1  •i 

/•  CCNST4I»ZI  • PULl«  ItCPC*  OP  CCKSTPPI  * 

/P  CCNS1C1«SI  • INlfPNM  IVPtCL  PPPf  *i 

/P  All  CGNSICIcll  APE  CMECPED  UPfll  MUll  fCUMC  P4 
/P  P/ 


DO  FOP  EACM  SUSNCOE  OF  I 
IHPUTf^CPDI 
3ET  (I  • 1) 

DC  MNIIE  CQNS14I*11  <>  «•  AND  CCPS141vl)  <>  P 
INCRENEN141) 

END 

If  CONST4I»ll  • «P  THEN  PESSAOE 4a»«l««IN«AlIC  lPPtT«l 
ELSE  IF  CONST 41»21  - ••  THEN 

SET  4«AiUE4CCNST4I#SI)  • pTESM 
EISE  DC 

lNPtT4«»») 

If  VAlUE4CCNS14I*En  > PhOPO*  THEN  IPFI/T 4llCPO I 
ELSE  IN^lTfOliNSTANT} 

SET4VAIUE4C0NST4I»SI I • Pl 
If  VALUE4CONST4I#2n  • •MORC*  THEN  CC 
SET  4VAIUE4CCNST4I»II1I 
00  NHILE  INPUT  CP  •^•1 

CATEIiATE4l»PI 
INPUT4MCPCI 
CATE»iATE4t*P) 

ENC 

END 

END 

END 

SET  41  • 1) 

00  WHILE  C0NST4I»1I  <>  •• 

IF  C0NSTfI*2l  • ••  ANO  V AIDE  4 VAt IE 4CCNST 4I»3  1 1 1 <>  'TES* 
THEN  SET  4VAlUE<CCNST4I»Slf  - pMCM 
ELSE  IF  VALlE(«AlUE4CONST4I«3in  • ••  THEN 

NESSACE4I-»*SlC0NSTANT  NCT  ATAILAEIE'I 
INCPENENT4I  } 

ENC 

END  CCN.PEAD 


Figure  C-1 
FCF  FOP  LINK4 
(page  6 of  41) 
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l4C0NTABt  /*  L1NK4»C0NSTANTS  OEFItllTlCN  *! 

DEFINE  CONSTI14»3l 

ENTFFf CONST fl»l)«<01STANCE.FRDF.%ANE.LEA0IN«.E0GE.1C.NAC*1 

ENTE.«(C0NSTf2»l)»«AlFA.CCNVERCENCE.CRnEFICN«l 

ENTER  ICONS!  ( 391  )•»  •AiFA.ITERATI  CN.Ll  NIT  •! 

ENTERfCONST(49ll»‘*CL.CONVfR6ENCE.CRItERlCN*l 

ENTER  ICONS!  (#»1»»*«CI.ITERATI0N.11NIT’*I 

ENTER  ICONS!  I6»1I*'«LCA0.FACT0R.0ATA.SCIRCE*I 

ENTER  ICONSTI1»lU«REFERENCE.ACCEL£RATtCN.OOE.1C.6RANllYM 

ENTER  ICONS!  I a»ll»«TMETA.E)IPDNEN1*) 

ENTERICONSTI«»ll9«ALFA.NON.CONVERCENCE*l 

ENTER  (CONST  110#  i)-9'CL.NON.CON\(ERCENCE  *1 

ENTER (CONST  111# 1)#*RECCNFUTE.CL*) 

ENTERtC0NST(12#ll#*C0NFUTE.C0*l 

ENTER (CONST (13#l}#*CaRRECT_F0R.FITCH.ACCELERATlCN*1 

ENTERIC0NSTI14#1)#*  M 

ENTERIC0NST(1#2I#«CCNS1ANT*I 

ENTER (CONST 1 2»2 If •CONSTANT*  I 

ENTER (CONST ( 3#2 If «CCNSTANT* I 

ENTER (CONST (4*2  I# 'CONSTANT*  I 

ENTER (CONST (9f 2 If 'CONSTANT*  I 

ENTER(C0NST(6f2l»«UCRD*l 

ENTER (CONST (7f2 If 'CONST ANT* I 

E NTER (CONST («#2 If ‘CONSTANT* I 

ENTER (CONST (4#2 If 'NORC* I 

ENTER(CONST(10#2I#*NCRO*I 

ENTER(C0NST(llf2l#*  *1 

ENTER(C0NST(12f2l»*  *1 

ENTER(C0NST(13f2l#*  *1 

ENTER (CONST (lf3l#'XlVC*  I 

ENTER(C0NST(2f 3 l*'CVALF4*« 

ENTER(C0NST(3#3I»'ITRALF*  I 
ENTER(CCNST(4f3lf 'CVCLT*! 

ENTERIC0NST(3f3l#'lTRCLT*l 
ENTER(C0NST(6f3l#'IS0lRC*l 
ENTER (CONST (T# 3 1# 'GR*! 

ENTER (CONST («f3l»«ETNETA* I 
ENTER (CONST (4*3  I# 'LCVAtF*! 

ENTERICONSTdOf  3I#*LCVCLT*I 
ENTER(CONST(llf 3I#*ICIT*  I 
ENTERICCNSTdZ.ai  f *ICDT*  I 
ENTER(CCNST(13#3l«*lO0CT*  I 
END  14C0NTAP 


Figure  C-1 
FCF  FOR  LINK4 
(page  7 of  41) 
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#«  LINKB  ONABIC  LAC-FRECllNCV  CCKSlilliTS  OEFINITICN  */ 


OfFIHE  CONSTfS*!) 

ENTER  f CONST  fl»l)*«CHARACTCItlS1IC_ARE«.CF.eCCF*1 

ENTER f CONST  <2*1  >»«NCNiNT.CF.INER1tA.OF.V«NE.iCCELERCFETFR'*  I 

ENTERICONSTO»1I*«*) 

ENTER (CONST ll»2)« •CONSTANT •> 

ENTER(C0NST(2»2}»«CCNSTANT*I 

ENTER(C0NST(l«31v«AeCCN'*) 

ENTER(C0NST(2*S1»«X1YT*) 

END  lADlFTAB 


Figure  C-1 
FCF  FOR  LINK4 
(page  8 of  41) 
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L4DIT«B<  /*  L1NK4  OVNABIC  LAC  CONSTANTS  OIFIMIIICK  *t 
OffINI  CONSTfC»S) 

ENTEIItCONSTa*ll»«AlFA.CON«iltCfNCf.CIIY1CnCN*l 

ENTEI((C0NST(2»ll*’*AlfA.ITERATICN.LlAIT*l 

ENTEA(CONYTff»lU 

•NUABER.CF.POINTS.REQLIXIIfD.TO.|lEEY.CN«CBCENCE.CBITEiXCNM 
ENTER  (C0lfYT(4»l)«'*CI«ARACTERISTI€.AREA.CF.VANE*l 
ENTERfCONYTf f »1 }»  «OCL70AIFA.FOR.TANE  • I 
ENTER  fCOKST (6*1 !• •CAINJCONSTANT ■ I 

ENTER  (CONST  (7*1  U'*OXSTANCE.FRON.«ANE.CC.‘TG.VANE.AEROOYNANXC.C  ENTER'*  1 
ENTER(CDNST(B*1*««) 

ENTER (CONST ( 1*2 l«*CCNSTANT* I 
ENTER(CONST(2*2)*<CCNSTANT*) 

ENTER (CONST (3*2 )*«CCNSTANT*1 
ENTER (CONST (4*2 )*«CCNSTANT*) 

ENTER(C0NST(S*2I*«CCNSTANT*I 
ENTER (CONST (6*2 >*«CCN5TANT*) 

ENTER (CONST (7*2 >*«CCNSTANT*) 

ENTER(CONST(l*3l*«XTROAIi*l 
ENTER(C0NST(2*3I*«CV0AM*I 
ENTER (CONST (3*3 •PCTOAN*  I 
ENTER (CONST (4*3 )*«AVANE^ ) 

ENTER  (CONST  ( 5*3  {•'•C  LAY*  I 
ENTER(C0NST(6*3U«XI(T*  I 
ENTER (CONST (7*3 l*«XL*  I 
ENO  14DLTAB 


Figure  C-1 
FCF  FOR  LINK4  , 
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L4tBT«M 


/4  I.INK4  BOOB  BENOINC  COPTSTBNTS  «/ 


OEfINE  CONSTU»ll 

ENTEB  fCONSTd*!  l9'*CMABACTERIS11C.BREil.CF.BCC(l  • I 

ENTER  fCCNSTf  {•!  I««OCL’/OALFA.RCR.BOON  *1 

ENTER  f CONST (3#1 )» •WEICHT.OF.BCCR • ) 

ENTERfCONSTCA*l)»«*l 

ENTERfC0NST(t*El**CCNS1ANT*l 

CNTERfC0NST(S«2l»«CCNS1ANT*) 

ENTER (CONST fl»SI««ABCCN*l 
ENTER (C0NST(2»3)9«CIAI*) 

ENTER  (CONST  (S*  S U««BOCN*  I 
END  lABBTAB 


Figure  C-1 
FCF  FOR  LINK4 
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L4irT»ei  LINK4  lOAP  FACTORS  CONSTANTS  *A 

OEfINE  C0NSTfA«3) 

CNTE*  <CCNST  tl#l >»«OATA.SOURCE • t 

ENTER f CONST C2»l)»«CC.ACCElER0NETiR.NISAltfiNNENT.ANClE*1 
ENTERfC0NSTl3#ll#«BC0N.ACCELER0NCTER.NlSALICRRENT.ANClE*l 
ENTERICONST(A»l)»«*l 
ENTER  f CONST  fl»2l9«N(;NBER*) 

ENTER  ICONST  12*2 1#  •NIiNBER*) 

ENTERtC0NST(3f2)»«NUNBER*l 
ENTER (C0NST<1*3}««J AXIS*  I 
ENTER fC0NSTf2«S>* •ACCRA *1 
ENTER(CONST(S»31*«ACCRAF*l 
ENO  LALFTAB 


Figure  C-1 
FCF  FOR  LINK! 
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PAR.KfAOt 


/•  READ  B-fllE  PARAMETER  NAMES  ANC  INITS  «/ 


AR  NAME  • NAME  CP  TABLE  PCR  STCRINC  NAPES  •/ 

/•  UNITS  • NAME  Cf  TABLE  PGR  STCR1N6  UNITS  «/ 
f NRAR  - NLNBER  OF  PARAMETERS  RfAE  fOLTFCTlR/ 

/«  FIRST  COUNT  NUMBER  OF  PARAMETERS  */ 

SAVE. POINTER 

INPUTfHORO  OR  STRINCI  ERRORt  MESSAGE!  I>*«VSNQ  PARAMETERS  SP£C1P1C0> 
SET  (NFAR  • II 
IP  INFUTfM*)  THEN  CO 
INPUTIWORO  OR  STRING) 

INPUT<«I«T 

ENC 

DO  MNTLE  INPUT!***) 

INCRfHENT!NPAR) 

INPUT!VORO  OR  STRING) 

IF  INPUT!**!*)  THEN  DO 
1NFUTIVORO  OR  STRING) 

INPUT !R»*) 

END 

ENC 

A«  NOW  READ  IN  NAMES  AND  UNITS  «/ 

RESTORE  POINTER 

DEFINE  VAIUE!NAM£)!NPARI*  VALUE!UNITS)!NPAR) 

INPUTIWORD  OR  STRING) 

ENTER!VAIU£!NAME) !1)  * *) 

IF  INPUT  !•!*)  TNEN  DC 
INPUTIWORD  OR  STRING) 

ENTER!VALUE!UNITS)!1)  « «) 

INPUT!*)*) 

ENC 

ELSE  ENTER!VALUE!UN1TS)!I)  * •'*! 

SET  !MPAR  • 1) 

DO  WHILE  INPUT!**  •) 

INPUTIWORD  OR  STRING) 

INCREMENTINPAR) 

ENTERIVALUEINAPEIINFAR)  * «) 

IF  INPUT  !*!*)  THEN  DC 
INPUTIWORD  HR  STRING) 

ENTER 1VALUE1UN1TS)INPAR)  * «) 

INPUT!*)*) 

END 

ELSE  ENTERIVALLEIUNITSICNPAR)  * **1 
ENC 

ENO  PAR.REAO 


F1gur«  C-1 
FCF  FOR  LINK4 
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FUNRCAO^i  /•  READ  CURVE  NUUBERS  OR  MlUR  A TABIE  ECR  lOOKiR  «/ 


y*  OUTRUT  i</ 

1*  FUR.TVE  • "CURVE*  CR  •TABLE*  •/ 

/*  RFIRIT  • FIRST  CURVE  RUBBER  •/ 

/•  RLAST  • LAST  CURVE  RUBBER  •/ 

'/A  DIMENSION  • CURVE  OR  TABLE  OIMENSIOR  •/ 

/*  FCR  • WHAT  FCLLCVS  •FL'NCTION.OF * <7 

/•  TABLE  • TABLE  flF  USED)  */ 


INBUTIVCRO  OR  *(*l 
SETfFCN  • A I 
If!  • - THEN  DC 
INBUTtVORO) 

CATENATE(S>A| 

EMC 

SETfOlBENSION  • 21 
SETfFCN) 

DO  WHILE  INBUT<*»«  CR  •♦*  OR  *-"  OR  "A*  CR  •/•  CR  •♦••  OR  •)•  OR  •••• 
OR  WORD) 

IF  A • THEN  INCREBENTIOIMENSICR) 

CATlNATEfDEFAULT*FCN*  A| 

EMC 

INBUTf«CND  OF  NODE*! 

IF  INFUT(*CURVE.NUNBfR*)  THEN  OC 
SETfFUR.TYB  • •CURVE* I 
INBUT (NUMBER  OR  WORD) 

SETfRFIRST  • A) 

IF  DIMENSION  • 4 THEN  00 
1NBUTC«»*I 

INBUTfNUMBER  CR  RCRC) 

SETfKLAST  • A} 

END 

ELSE  SETfRLASTO) 

EMC 

ELSE  CO 

INFUTf^TAELE*) 

SETCFUM.TYF  • *TABLE*) 

NVS3ACE(6-»*N*TABLE  READ  HAS  NCT  YET  BEEN  ORSIBNEO*) 

EMC 

END  FUN.REAO 
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l4.C0rf«0N<  /«  SETiP  IINK4  CONMCN  BICCRS  •/ 

IF  FRFO  • •CURVE*  OR  OANF  • 'CURVE*  CR  OABE  - •VES*  1HEH 

EMTERfFASSl»VCORCURVE»*CCRFON  ACIRVES#  ClRVEIltOOl*  iCCATKAI'l 
FISE  ENTERfFASSl»tCCnCURVE*«*l 

SETfCCRLATNTR  • «CORMON  /L4INTR/  NRER«  RERARRUOl*  NRSECT#  NSC*  AENO*f 
If  OAV  • •VES*  TMEH  DC 
SF1fCaRL4IN1R) 

CATENATE(f»**lAOUT»IBOUT«IAIN»IBIN»LAFOVR»NlF«flClRI*l 

ENC 

IF  FRIO  - 'CURVE*  OR  DAMP  • 'CURVE*  CR  OABB  > 'CURVE*  THEN  00 
SET  CC0NL4INTR1 
CA1ENATE(8»*»K0IH*LCC*I 
ENC 

ENtERfFASSl»fCONL40AT**CONNON  FL40ATA/  CVAIF«C VCL1«CV0AM» I CBU(4»  *1 
CATENATlfB**I0»ISF4»ITRALF*ITRCl1*lTRDAV»N0AB»*NFAlF9RLALF«RlfFV#*l 
CATENATEt»«*0ZV»HB*RF«NANC4*FCT0AV»SinF«l 
END  14.CONNON 
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l4MtlO«  /*  OifIME  LINK4  B FILE  NABES  AND  CCFBCN  BTCBACE  •/ 

INVOKE  L4FAR1N  /•  OfFlNE  INKUT  FABAKE1ERS  *! 

/*  BUtlO  IIFFUT  CONNON  BLOCK 
SCtCNfAK  • N.1N.FARI 
SfTfCCNNAKE  • •COKINM 
SETfNANE  • •ENIN*  I 
SETtUKITS  • •FUINM 

SETfCOiriN  • «CONHCN  /LAIN/  TINE  flOIN*! 

INVOKE  CONBUILO 

BUllD  TNFUT  DATA  STATENENTB  «/ 

BETfFNtNl  • "OATA  NN1/*I 
SCTfFNtNZ  • "DATA  NNEV'I 
SEtfOATAl  ■ •NNINX'I 
SETfOATAE  • •ENINEM 
INVOKE  OATABillLO 

INVOKE  L4FAROUT  OEFINE  COTFUT  FANAHETEIIS  «/ 

/•  BintO  OUTFUT  CONNON  BICCK  4/ 

SETINVAK  • N.QUT.EAB) 

SET(CCNNANE««CONOtT*l 
SETtNANE  > «NNOUTM 
SEKUKTTS  - •PUOUT*) 

SEKCONTN  • «CONNON  /L4CUT/*} 

INVOKE  CONBUILO 

/«  BUTLO  OUTPUT  DATA  STATENENTS  «/ 

SETCFNOUTl  - «OATA  PNl/M 
SETCFN0UT2  - •DATA  PN2/'I 
SETfOATAl  - «PNOU11*l 
SETIOATAZ  - •PN0UT2M 
INVOKE  OATABUILO 
END  L4FAPtO 
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UNCLASSIFIED 
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6-79 


l4PARINt 


/*  DEFINE  e FILE  INFL'TS  •/ 


DEFINE  PNINC27«N.IN.FAF}*  PUIN (27«N.IN. FAN  I 
ENTEPfEHINID*  •ALFAN*) 

ENTEP(PNINI2I»  •APC7*) 

ENTER(PNlNf3l»  «OAT*l 
ENTER<PNIN(4I*  'DITM 
ENTERfPNINO)»  'CCT*) 

ENTEIt<PNIN(61«  'FETM 
ENTERfPNIN(7}9  •F«T*1 
ENTERfPNTNffl),  •FRT<I 
ENTER(PNIN(«)»  •P»l 
ENTER  fPNTNflO)*  *01 
ENTERCPNINdlt*  •COCTM 
ENTERfPN1N(12)»  •CBARI't 
FNTER(FNIN<13)*  "R'l 
FNTERIPNINfl^)*  "^IHATM 
ENTERCPNIN(15)9  •TH2T*) 

ENTERfPNIHIiei*  •TTTM 
ENTERfFNlNfl7l>  •liFr*l 
SET(N>17I 

IF  JAXn«2  OR  JAX1S«4  CR  JAXIS-B  THEN  CC 
INCRCNENT(N) 

ENTER(PNINfN)>«XNXN«l 

ENG 

ELSE  IF  JAXIS-1  OR  JAXIS-6  OR  JAXI$*7  THEN  DC 
INCRfNENTfN) 

FNTER(PNIN<N)f •XNXNP*} 

ENC 

IF  JAXIS-2  OR  JAXI$-3  CR  lAXIS-T  OR  ISCtlRC>2  THEN  DC 
INCRCNENTfNI 
ENTER(PNINCN)««XNXN*1 
END 

ELSE  IF  JAXIS-1  OR  JAXIS-3  OR  4AXIS-f  CR  ISOLRC-l  THEN  CC 
INCRCNENTINI 
ENTERfPNINtN)»*XN2NP'l 
ENC 

TF  JAX1S-4  OR  JAXlS-6  CR  JAXIS-T  OR  ISCIiRC>2  THEN  CC 
INCRENENTfN) 

ENTER  (TNINfN)»«XNZNTM 
ENC 

IF  JAXIS-3  OR  JAXIS-S  CR  JAXIS-T  THEN  CC 
INCRFNENTfN} 

ENTER(fNIN<Nl»<XNXIlTM 

ENC 

IF  LOCOT-'«YES*  THEN  DC 
INCRENENTENI 
ENTERfPNIN(N}«'«QCCTM 
XNCRENENTENI 
ENTERfPNIN(NI««0*} 

ENTERtFUINfN)««  TMC*I 
ENC 

IF  OAN-«YES«  THEN  DC 
INCRCNENTENI 
ENTEREPNlNfN}*  •AIFAPM 
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1 


ENTfRCruiNCNI**  1llC«l 
INCfffNCNTfNI 
ENTERI^NIN(NI««AiFAf>*« 
ENtfR(PUINCNI»«  THREE*! 
EKC 

IF  H.IH.FAR  > 0 THEN  OC 
SETtNADD  • N.IN.FAR) 
SfTINAHE  • •FNIH*) 
SETCUNITS  • •FIIH*» 
jETCAOON  • •IN.FARN*) 
TETfAOOU  • •IN.RARU'I 
INVOKE  AOO.PAR 
ENC 

SETCH.1N.RAR  • N^N.IN.RAR) 

END  14PARIN 
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l4fARCUTt 


/•  OEflNi  e FILE  CUIfUT  FRRARETERS  •/ 


DEFINE  RN0UTI2O«N.0LT.PARl»  RUOtl (M«R.CU1_FRR  I 
ENTER(FN0U1(1)>  •ALFAT*  ) 

ENTERfVN0UT(2)»  ■CL1*  » 

ENTERfENOUTOl*  •FEV1*  ) 

ENTERffNOUTtAlf  •FNDA*  I 
EHTERfFNOUTISI*  •FN0T2*  ) 

ENTfR(RH0UT(6l»  •FNl*  I 
ENTERfRNOUTCTI*  •HETOCl*! 

ENTERtEHOUKR)*  <SFCQRA*I 
ENTERfFNOUTfEI*  •SFCOR’I*! 

ENTERfRNOl)T<lA)l»«1SFC*  I 
ENTERfENOUTdllv*  VNZM1P*I 
SETfN-llI 

IF  JAIIS  <>A  AND  JAXISOA  AND  dAXIS<>E  IFEN  CC 
INCRCNENKNI 
EN1ER(FN0UTfN)»«)iNl«i1*l 
ENC 

IF  JAIIS  <>3  AND  JAXIS05  AND  JAIIS<>E  THEN  CC 
INCRFNENT4N1 
ENTER(FN0UT(NI»«INXN1*I 
ENC 

IF  ICCT  . 'YES*  THEN  DC 
INCRfNENKNI 
ENTERfFNCtIf NI»«C0T*l 
ENC 

IF  OAPB  • 'YES'  THEN  DC 
INCRENENTINI 
ENTER(FNCiJT(NI««DABC*  I 
ENC 

IF  OAC  • «YES»  THEN  DC 
INCRf  NFNKNI 
ENTERfFNOtT(NI*«CAC*l 
ENC 

IF  OAt  • '•YES*  THEN  DC 
INCRENENTfNl 
ENTER(FN01JT(NI»*0AL*) 

ENC 

IF  DAN  • •YES*  THEN  DC 
INCRf  NFNKNI 
ENTCRIFNC(JTfNI**OAN  *1 
ENC 

IF  AlCORUP  0 •YES*  THEN  DC 
INCRENENKNI 
ENTER  ( PNCUKNI  >*  DAL  FA  * I 
ENC 

IF  N_Cl)T_PAB  > 9 THEN  OC 
SETfNAOO  • N.OLT.PARI 
SEKNANE  • •PNCUT'I 
SETfUNITS  - •PL01T*I 
SETtAOCN  > •OUT.FARN*) 

SfKADOU  • •OUT.PARL'*!  '! 

INVPKf  ADO.PAR 

ENC 

SETCR.OtT.FAR  ■ N^N.OUT.PARI 
END  lAPARCUT 

Figure  C-1 
FCF  FOR  LINK4 
(page  18  of  41) 


C-19 


AOO_P*»-« 


/•  AOO  rANIMriERS  «/ 


f NAHi  • TABLE  NAPE  CONTAININC  S1ANOABO  TABAPETEA  NAPEiS  */ 

/•  UNITS  • TABLE  NAPE  CONTAININC  71ANOABR  PABAPETER  LNITS  •/ 

/•  AOON  • TABLE  NAPE  CONTAININC  ADDED  PABAPETEB  NAPES  •f 

/•  ADOU  • TABLE  NAPE  CONTAININC  ADDED  PABAPETEB  UNT1S 

/AN*  NUPBER  OP  STANDARD  PARANETEBS  */ 

/A  NAOO  • NUPBER  OP  PARAPETERS  TC  BE  ADDED  •/ 

SETII  • 1» 

DO  UNTIE  l<-NAOO 
SETfJ  - 1) 

DC  UNTIE  J<«N 

ANO  VALUEfVALUECNAPEMin  «>  VALLE  IBALUE  (AOON  ) fj  11 
AND  VALUEfVAlUECUNITSMino  VALLE  (VALUE  (ADOU  MJ  1) 
INCBEPENTfJ  I 
END 

If  J<-N  TNEN  DC 
TNCBEPENT(N) 

ENTER (VALUE (NAPE l(N I#  VALUE (VALUE (ADDN I ( 1 1 1 I 
ENTPB(VALUE  (UN1TSMN)*  VALUE(  VAiUE  ( AODl  MI  1 1 I 
END 

INCRfPENT(I) 

END 

END  ADD.PAR 


i' 

i 

I ' 

i . 
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ccneuiiot  /*  euiio  cchi^on  block  fon  e fiiE  k«k«heieks  «/ 

'/•  NfAB  • KUKBfB  Of  PABARETEBS  «/ 

/•  CQKNAKE  • HARE  Of  CORSTART  IRTC  RRICN  CORKOR  S^IATEHENT 
/*  10  BE  S10RE0 

/•  RARE  • RARE  CF  TABLE  C0N1AERIR6  FABARETEA  RARE! 

/•  URITS  • RARE  CF  TABLE  CORTAIMRC  FABARETEB  URITS  i«/ 

CATERATf  (OEf  AliLT»VAlUE(COFRAREI«  VALLE  CVAltE  (R  ARE  Ml  1 1 I 
TF  VALUE IVALbEfURlTSMin  <>  «•  1HER 

If  VAlUEfVALUEtURITSMin  > • TRO*  THER 
CATfRATE(OEfAULT0«AI.UEfCORRAREI««2*1 
ELSE  If  VALUEIURITSHin  • • THREE*  THER 
CATERATECDEFAULT»VAtUE(CORRAREI««S*} 

ELSE  RESSA6EMIS  ILLEfiAL  URITS*! 

CATERATELOEFAULTy VALUE fCORRAHEI»  *fICIR*1 

SETH  • 21 
DO  MNILE  7<-RPAR 

CATERATE<OEFAULT*VALUE(COHRARE}»  • VALL'ELVALUE  (HARE  Ml  M > 

IF  VALUE(VALUE(UR11SMII!  **  •*  TREK 

IF  VALUE(VALUE(URI1SMII  1 • • TVC*  THEP 
CATERA1E (DEFAULT* VALUE (CORRAREI*  *2*1 
ELSE  If  VALLE(VALUE(URITSMin  > * THREE*  THER 
CATERATE (OEFAULT«VALUE (CORRARE 1*  *3*1 
ELSE  RESSA«E(I»*S«ILLE«AL  URITS*! 

CATEHATE(OEFAULT*VAtUE (CORRARE!*  «BICtR*! 

IRCBEREHTd! 

ERO 

ERO  CCRBUILO 
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0ATAB111D« 


/•  BlILO  fABAMfTi*  NANB  DATA  STITIBENTS  *t 


/•  NEAR  - NUftlEA  OE  EAAAMETERS  «/ 

/•  OATAl  • NAEC  Of  CONS1AN1  IRTC  VMICM  NAME  DATA  SIITl  STOAEC*/ 
DATA2  • NAAE  OF  CCNSlANT  IMC  WHICF  UNITS  DATA  STFT  *t 

/*  STCAEC  •/ 

/*  NAME  • NAME  CF  TABLE  CONTAININC  FAFAME1EF  NAMES 
/«  UNITS  • NAME  OF  TABLE  CONTAININC  FAFAMITER  UNITS  «/ 

CATENATE  I DEFAULT*  VALUE  fOATAll^  LENCTHf  VALUE  (NAFEMl  1 1* 

VALUEINAFEICSl  1 

IF  LfNeTHlVAltEfUNITSI(ll)  > « THEN  CATfNATC fOEFALlT* VALUE (OATA2 U 
Lf  NCTN  IVAlUit UNITS  > II ) I^^N SVAlUf  f UNITS  HIM 
ELSE  CATENATEfOEFAULT*VALUECOATA2l»  «1M  *•) 

SETINEIANICOI 

SETn«2l 

DO  MMTIE  I <•  NFAR 

CATENATEI0EFAULT«VAIUE(0ATA11»  flENCTMlVALUf CNAMEM1II»'«H** 

VALUSINAFEMI)  ) 

IF  VAlUEIVALUEfUMlTSHIII  • «•  THEN  INCREMENT  INIl  ANN  I 
EITE  DC 

TF  NBLANR  > 0 TNEN  DO 

CATENATE IOEPAUIT»VAIUEIOATA2 I*  «*«»NBLANN* •«1N  •} 

5ETINILANK««I 

END 

CATENATEf0EFAULT*VALUEI0ATA2»«  •••«LENCTMfVAlUE(UNITSH I> 
*N*»VALUEftNITS)tl)  ) 

END 

INCRCMENTUI 

END 

IF  NBIANK  > « THEN 

CATENATEIOEf AULT»VAlUE<OATA2)»  »NeLANN*^AlN  'V 

C ATENATIIDEFAULT*  VALUE  lOATAD*  «/•! 

C ATENATl (DEFAULT* VALUE <0ATA2)« 

END  OATABIILC 
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P 

P IfNK^rt  /*  L1NK4  MXTN  lUFFfR  OtNAPIC  l«C)  •/ 

OVEHAYf  TFEXT#  4*0) 

PBCrUAM  11NK4 


PEPPQPHINCF  TEST  CONOllICNS  PRIHtPY  CVERLfY 

THT«  PRCCRA*'  CCNTBOIS  C«\CUIATICM  CF  1E51  FFhFCBPANCE  FAPAMtlERiS, 

ns  CNIY  FUNCTICN  IS  10  CALL  INTC  EXECLTICK  THE  SICCFCAPt 

OVERIAYS  TNFUT4»  OAIAC  AAC  SFEXl, 

««4««n(1YF  - THE  three  "CVERIAY  CAllS"  IN  THIS  FRLCRAH  ARE  NCN-ANSI, 


COPHON  / All/lUIN»ll  OL'T»LL'CURV»lTHPtS*S»  XIF»CFCRC 
• r fHl AOAT 

Cn»«MCN  yilOATA/  2t'C»  NCFLAG 


OUTrUTCCONINvfl 
OUTPUKCONOUTff) 
trOHCURVE 
P OUTPUT fC0Nt41NT»»t) 

cnHHOK  /SAVALF/  XURVIA 
CPPHrN  /SXvrAU/  KtRVl>CVOAt (400 ) 
KHPVTA  • C 
KlIPVT  ■ C 
N?r  > C 
WRITF  (6f60<'ln) 

6000  FCRPAT  (lAHOFNTERED  HNK4) 

If  CAtl  CVFRl AY(&hSFEXT»4«l ) 

IF  iNOFlir  ,FQ  *3)  GC  TC 
CAll  CVERIAY(5mSFEXT*4*1  ) 

CAIl  0VEPlAYt>HSFEXT#4»3) 

IF  ( SFNT  .NF*  1 ) GO  TC 
<!<)<}  WPTTFI6>6«49I 
6S4S  FORNATnT>'rFXIT  11NK4  ) 

EMC 

P END  LINR4B 
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• IHPUT4BI 

OVPOIAV  (SFFXT»4»1) 
PorrpAH  IKPIT4 


ir^K4  PIIF  T^JPLT  SECCNCiHX  CVERLit 

PRCfRAH  LOADS  NEEDED  CLRVES  FRCH  A CIPVE  FILE  IMt  CCRE  AN  t 

RFATS  FARAPETERS  FRCN  AN  INPUT  B FILE*  TFESE  CIFVES  AND  B FILE 

PARAMETER  VALLES  ARfc  THEN  PASSED  Tt  THE  riFER  LINK4  SECCNOAR^ 

OVERLAYS  (PAL AGtSFEXT  I THROUGH  CCHPON  BLCCPS  FOP  FRCCESSING* 

» *****  ******  ********  >***************«  *^*  *«  **^*«>**«»«»****«A«*******  **  * * 

rOPNON  FAIL/  LL'TN»LUCUT>LLCLRV#ITHRLS«S>X1F»CHCRC 
• CCPI  APAT 

CPPPPN  /LIOATA/  /UC»  noflag 

» aUTfUl<COPIN»tl 

* OUTRUTfCONOUTfB) 

Arcpci'RVf 

» OUTRUTfCONl4INTIL*fl 

niPENSTCN  RNKAIDIN)*  FNZLRLOIN)#  VAL  ( A L C 61  F*  Al  C IN  )#  TNJ(?00)»  TiF2(2AO)» 
« IT<:TNC(200  )*  V(200) 

FOt'IVALENCE  ( VAl  (i  ) * AL  F AP  (1  ) ) 

> OUTPUTffNINl-*#  I 

> OUTPUT <PNIN2»f) 

NVAP  > AlCIN 

KPTP  • ICOO 
s«:r  « NSC41 
HOTTF  (ft»6'OWlO> 

6000  F0R»*AT  (I^MOFNTFRED  INFUTA*//) 

IF  (N«G*CT*1 » GC  TC  20C 


PRINT  INFITS* 


6 WR TTP L6.6T01 ) LL IN» L LCL T » I LCURV t LTHRUS * S » >1 F » CH C P C 
6101  FnRPAT«6*»32HPAPAPETERS  FRCP  CCHPCN  BLOCK  AH»/» 

110Y»THLVTN  .,!•  » /.iOX»THLUOUT  -tlS  * />10>*7HILCUNV •» TS  , /# 
210Y.THI TFRUS-,LS  »/»10X»7HS  - *E LA .6 » /« 1 C X * 7H> I F -tElA.A,  /, 

inXfXNCNCRC  -tflA.E*/) 

WRITF  (6»610?)  CVAIF»CVC11>CV0AW»IC6UGA>1C>TSPA«1TRALF*ITRCLT» 
lKrAPp,KFAlF»KFCAU»KLALF»KLrAL»KMNV*K7V»PP»PF,NANCA,FrTtAV»SDlf 
?KnARP»KFAlF»KF0ALtKLALF»KlCAL»KWNV»K2V# 

610?  FrRPAT(6X,3«HPAFAPETFRS  FhCP  OOMPCN  ELCCK  lACATAf/* 

llOX.fMrVALF  -tElA.B*  /•ldX,7HCVCLl  •* EX A* ( « /» 10 X* 7H C VC  AW  -*ElA.6»/> 


?iO)t,7HTrFl’CA«,  If 
^lO*.‘*HlTP»Lr»,li 


•lOTl,  "'HK  F »l  f 
AlOX. THKI tat 
7lOX,-»NVp 
P.0»,7HNAKCA 

viox.  YMsrT*^ 

RFVINP  I I T» 

P F W T N r I • C I T 

T f r • Y 

I APOVR  • (PF 

If  FBEO  • 

PC 


«/»I0X»7FIC  -»I6 

• /. 10X.7H11BCLT 

lOX,  /#10X, 7HKCAPP 
»/»10X»7HKFUAl  ■*15 
» /»  10X,-»HKWNV  'rib 
. /» 10X,7HPF  •tlb 
»/»1uX»YhNRFHA  -flA 


./»1CX»7HTSH  •» IS  . /» 

* /*10X  ,7P  nwOAV  *.  u . / , 
• » I 1 * / » 

» / • l,w  X»7HKI.AIF  “pis  »/> 
» /»10X,7HKZV  -»  i;  , I, 
» 1 1 

»/>xOX*7HFC1CAW-pE1A.6»  t» 


■pE1«>.6) 


♦ Pb  ♦ l)/2 

•CURVE*  OR  OANP 


• 'CURVE*  OR  OABB  • *TES*  THEN 
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c— — load  rtAXfS  TNTL  T^e  AHRAt  CURVi--- — 

P TF  f*EO  - •CURVE*  IREN 

c kwNV  ••ACC^F  • F(NACHf CTeARI*«*USEO  IN  0AlAC«««eEC  INS  AT  LCCATFt:) 

P IF  DANE  > «CURVE*  THEN 

c .KZV  ••ACrCR  ■ F(NACF»CTeAR  )»««UIEC  IN  C A I AC  • ••  E E C INS  AT  ICCATEd) 

P If  OABE  > •CURVE*  THEN 

c KDARR*,  CAPP  - F(FB)  •••USEC  IN  SC A •£••• EE C INS  AT  ICCA1E(!) 


LT'"  • 1 

P OffINE  TABlEfSI*  KURVdl 

P ENTER  fTABlEfl)»FRECI 

P ENTER  (KURVfl)«KFRECI 

P ENTER  fTABLE(tl#OANPI 

P ENTER  fKURV(21»NSANPI 

P ENTER  fTABLE<SI*OABBI 

P ENTER  fKURVtlUROABBI 

P SET  fl  - 11 

P DC  VHILE  I <-  3 

P IE  VALUEdABLEf  III  > «CURVE*  TNEN 

P CO 

P ENTER  fPASSl«N»II 

P ENTER  (PASSS»N«VALUEfKURVII M ) 

I nCATE(N ) -IOC 

CAll  rRFAn(K,ltCLRV»CURVE(LCC)*lFl»lCPt  C4 ) 

IGC  ■ IfCPIFl 
NO  • rUPVF(lCC«A» 

NX  • CURVE (I rc^z ) 

N7  - ruPVE(lOC43) 

LHC  • ICC  ♦ NX  4 NZ  ♦ (NX  4 NO  > 2)  4 T 
P END 

P INCRENENTdl 

P END 

P OEIETE  (PASS1*NI 

P OEIETE  <PASS1*NI 

TF  (I CC  .IT,  KDTN)  CO  TC  100 
TCr  - 0 

WP  ITF(6»PP90)  LCC 

6t«!C  FnPNAT("H  ERROR  IN  INFUT4*  SIZE  CF  ARRAT  CURVE  PIST  PE  INCREASE# 
4 lAFC  TP  AT  LEAST  »I5»1N*» 


IOC  CONTINUE 

P CIEAR.TABIE  tTABlE) 

P CIEAR.TABIE  (KURVI 

P ENC 

C ....... 

c TNPLT  P file  LAEEL  RECCRC— — 

READ  (IL'IN)  1»NRSECT»NR#  (L*  I>i«NR  )»  NL  A P>  (TM  ( I)  # TN2  ( 11#  L ISTN  C (I  )# 
4 T>l»NlAe) 

CAll  IAP50R  (PNl»PN2»TNl»TN2»LISTN0>NUP*NVAR4l#MAP) 
r nETFPPTNF  IF  NcEDEO  FARAPETERS  ARE  AVAIIAPIE 


no  ITO  T-14NVAR 
IF  (NUN(n«GT«OI  GC  TC  lAO 

C NEECFO  PARAPETER  NCT  AVAILABLE 

MC  WRTTF(6»6140I  PN](II»  FN2ftl 
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614C  FOPHATCZCH  EDPCP  IN  LINK4*  FARAPCUft  »2A«»1PF  NIT  A\All»FLE  CN  # 
♦ 1*HINHT  e FItE*l 

TGC  • 0 
19C  CQNTTNUF 


•IF  A^•v  FPPCF*  WERE  ENCCUNIEREO*  5ET  NDFLA€*S  ANC  RETIFN* 


TF  <IGr«EC«0)  Nt)FLA6>S 

IF  rirCvFO.O)  CC  TC  2T0 

lATN  - 1 

lACUT  • 1 

IPIN  • 6C 

r.n  TC  2?1C 


• UVEPIAP  INPl'T  AFRAYS— — 


?flC  roFTTmif 

IF  (I APrVP.EC.O  ) 6C  TO 

I*  ■ 2*lAPOVP 

lATN  • lA^l 

lACT  ■ IAPPVR41 

TP  ■ 60- I A 

on  ?10  T«1»IA 

IP  • TP«1 

TiPEdI  • TTNE(IF) 

nr  2TC  j-i»nvar 

VAKTvJT  - VALdPtJ) 
?1C  CONTINUE 


P lINK4|t 

OVE»l4Y!?FE)rT,4fO) 
«»POC'»*N  ITNK4 


C PEPFn»r<«KCf  TfST  CCNCITICNS  PRIMARY  CVERLIY 

r TH?  PRCGRRP  CCNTROtS  CRICLIRTICM  CF  TES1  FFRfCRPRNCE  FPR4PE1ER'!# 

r ns  ONIY  fl^CTlCN  IS  TC  CRtl  IMTC  EXECITICF  THE  StERtOTlKES 

C THPUT4  RNP  SFFXT. 


COPH^IN  /!(  LVlUlH.llOUT»H.CURV*LTHRLS»S*>JF.CFCPr 
•rCHlAORT 

rOPHCN  rilDRTR/  7tC»  NOFLRG 


P OUTPUTfCOPl41NTR*f I 

NSC  • « 

WRITE  (6»600C) 

600C  FORMAT  (lAHflENTEKEC  LUKA) 
10  CAU  INPLT4 

<JENC  .fC.  1)  GO  TC  040 
CALI  'FE>T 

cr  TC  to 

OQO  WP TTE(6»E0C9I 
6004  FrRHAT(lTH<OEXIT  LINKA  » 

FNP 

P END  ITNROA 
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p 

p 


"1 


INPUT4t 

/•  MITMODT  OYNAHIC.LAC  •/ 

/•  (If  DATA  BUFAEAI  •* 

SUAPOtTUf  (►PCIA 

C IIKK*  PIIE  INPUT  SECCNCAAt  SUBRCllTINE 

C TNI5  PPCCPAP  CCAOS  NEECEt  CIBVE5  PACK  A ClAVe  fllE  INTC  CCPE  AN t 

C PPAOS  PARANFTEPS  EACH  AN  INPUT  A FILE*  TFESE  CLAVES  AKC  B FILE 

C PAAANPTFP  VALIES  ARE  THEN  PASSEC  TC  THE  CIFER  LINNA  SUEACLTlNE 

C TPPCIGH  CCPNON  BICCKS  FCA  PROCESSING* 

C-— 

CCPNON  /All/  tLlN»LUCUT»lLCl'AV»LTFALS.S^>lF»CHCRC 
•f CNl APAT 

rrPNpN  /IIPATA/  ZUO»  NCFIAG 

c 

P OUTPUT(CONIN*tl 

P OUTAUT(COHO(JT*f ) 

•crnrup VE 

Olf'^NSTCN  PMi(«iniN)»  PN2(#L0IN)»  VAI(AICIN)»  TN2(20Ct»  TN2(2C0)* 

« IISTNC(20J)«  V<200l 

tOl'TVAIFNCF  (VAl  (1  ),  AL  FAP  ) 

P OUTPUTfPNINlvtl 

P OUTPUT(PNIN2»t) 

MV»P  ■ •ICIN' 

KPT^  - TCOP 
- NSC  ♦ i 
(N.NOOir) 

<«OoO  FOP“AT  (l«HOFNTEREC  INFUTA.//) 

IF  (N^G  .GT.  1)  GC  TC  20C 


C- 

G- 

C- 


• PPTF'T  TNFLT«- 


t 

6101 


taPlTF(6»  61.01)  LIIN»LICIT.LICUAV»LTHAUS»S*>1F.CNCAC 
FrP“AT»6)«.?2HPARANETEHS  FRCP  CCHPCN  ELCCK  All,/, 

UO*,ihlITN'  -*15  . /,  10>»7H  UCUT  -,15  , /,  lO,  ? H ICUR  \ , I 5 » /, 
210*,7HI  lt-Pl'?«*L!  ,/,iO)i,TFS  « ,E  1 A*E  , / ,1CX  ,7F  > 1 F •,ElA*e»<, 

3lO>,*’MCHCPr  •,E1A*6*/) 

WPITP  (f,B10?)  CVALF,CVCIT,CV0AW,  IDPUGA,U,TSPA,  ITFALF,  ITPCLT, 
llTA0AW,NCAeP,KFALF,KFDAl,NLAlF,KlCAl,KVNV,N2V,PB,PF«NANCA, 
rPCTOAW, 5CIF 

N1C2  FGRNATlAX.If HPAAANETERS  FACN  CCMPCN  BLCCN  lACATA,/, 

110V,7NrVALF  >,E1A*6, /f J0X,7HCVCLT  • * El A*e  , / ,10X , 7FC VO  A V >,EiA«6,/, 


2E1  A,6,/,10X,7HirBUGA«,  15  ,/*lOX-,7HO 


15 


, /, 


3LOX,7hI?N  -,15 
410X.1HI TPALF-,  11 


If 

•*15 
-,  15 
-•If 


P 

P 


tlOXf'FHRFALF 
TlOV.’FNRirAl' 

P/  ,T0X,7FPP 
91<1X.7HNANf  A 
PIOX.TNSCIF  -fElA.A) 
PEWINP  ILIN 

NFWTNC  iin  T 

If  DAPB 
OC 


, /, lOX, 

» /,  lCX,7NITRCn-»  15 
10X,/*l^X,7HKCAPn 
, /,10X,7NKFOAL  -,15 
, /. ]0X,7NPNNV 
,/,10X,7NPF 
, /, ]0X,7HNREPA 


, /, 


•»I5 

-,15 

•*I5 


,/,1CX,7FITR0AV>, I! 

>,1!  »/, 

,/*lCX,7NNLALF  -,15 
,/#10>,7FNZV  •0li 
, / , 

,/,10>,7HFCTCAV«,ElA*o,  /, 


, /, 
, /, 


• ’YES*  THEN 
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[;- LPftP  ruBve?;  imr  the  array  clrve 

c KDAAP,,  TAPB  ■ F(FB)  IN  SO  A P E*  ••  6 E G INS  AI  LCCA1£(!) 

irr  - 1 

LCCATFO)  • 1 

P OUTPUT(«CALL  CRE AO ( SKOABB* •vLUCURVaCUR VE f 1 1* If ]» I0B164  ) II 

IGC  - IGC  * IFl 
NO  - CUPVP(2) 

NX  • rustvEO) 

N7  • riRVE(A) 

L0C-^'X4NZ*  (NX4F0-2)  + e 
IP  (toe  .LT.  KOIM)  CO  TC  ICO 
IGC  « 0 

WRTTF(6»6090)  LCC 

BC90  Fr)RHAT(«9H  FRRCR  IN  TNFUTA*  SIZE  CF  ARRAY  CURVE  MSI  BE  INCREASE* 
♦ lAHC  TO  AT  LEAST  *I$*1F.) 

100  CONTINUE 
P ENO 


READ  INPUT  P FILE  LABEL  RECCRO 


RFAD  (IL'INI  L*NRSFCT*NREN*(REPARK(I)*I-1*NREM*  NLAE*  (TNI  ( I )* 
« TN2( I)*L1STNG( I)*I-l*NLAe) 

CALL  LABSOR  (PN1*PN2*TN1*TN2» LISTNC»NUN>N VAP«l*NLAe I 


OFTERHINE  IF  NEEDED  PARAPETERS  ARE  AVAIIAELF 


DC  ISO  I-1»NVAB 

IF  (NUPd  UGT.O ) C-C  TO  190 

C NEFDFO  PAPAPETER  NOT  AVAILAPLE- 

lAC  WRTTE(6»C14lO)  »N1(I)*  FN2<n 

MAC  C0RHAT(28H  ERRCR  IN  LINKA*  PARAPETER  *2AE*]eH  NCI  AVAIIAELE  CN  * 
♦ 13H1NPUT  8 FILE*) 

IGC  - 0 


If  ANY  ERRORS  WERE  ENCCUNTEREO*  SET  NOFlAG-3  ANC  RETURN 


190  IF  riGC  •FO*  0)  NOFLAG  - 3 
IF  (ICO  .EC.  0)  CO  TO  260 


READ  VAILF-^  fOR  FARAPETERS 


znc  READ  (llIN)  N»T*  (V(J  )*  J-1*N  ) 
TF  (N  .NE.  01  GO  TO  270 
T2  ■ 0 
Z ■ 0 

WRITf(LlCUT)  IZ,Z,Z 
260  JENP  • 1 
27C  RETURN 
END 

ENO  INRUTA 
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1 


P SffKT* 

P JP  • 'ViS*  TNiN 

P oc 

nVF»lAY 

P EMC 

P ElSf 

<:iiB«ruTUF  5Ff)n 

f 

c TFST  FKCF55  IHHISI  SECCN04RY  CVERIIY 

C THT^  S^rrupARY  CVERLAY  CCMPLTES  the  WOCf  PEKCIFf#  LFkASF  ANf 

C — PlTTH  RATF  CCRPFCTICNS  Tf  THE  ANGLE  OF  ATTACH  ( C ABR#  FAl  > C AC  ) » 

C TPIlf  ANCIF  CF  ATIACK  <ALFAT>»  LCAO  FACTCRS  LIFT 

r CrFfFTCI'NTS  <CIT»CCT)*  RATE  CF  CHANGE  CF  ENERGY  HFI6HT  (HETCCTIf 

r #Nn  FYCF^S  THFL5T  (FfAT)  FO«  TEST  CONCTTICNS*  IT  THEN  RPITES  ThEH 

C fN  THF  rUTRLT  f FILE* 

C 

rCHKCN  /ALl/  I LIN»LCCtT»lLCURV»LTHRlS» JfXlFfCFCRC 
»r  c“L  Am 

c 

P OUTPL'TfCONIN#f ) 

P OUTFUTtCONOU1*f  I 

«r  rHCL'RYF 

P OUTFUr fCONLAINTR*ll 

P TF  DAW  • ^YES*  THEN 

P OC 


rnfHUN  /<:AVAt F / klrvi 
OIRFNfICN  YIVFALCPLFJ 
EOIYVALFHCF  »XLV(A)»FET0CT(1)  ) 

ITHFNSICN  V ( ALOeCF  »tLOCUT  »* F Nl ( t L T CL T ) » PN2 L ♦ L C CL T ) 
FCITVAIFNCF  (V(i  )> yN2bT(  1 n 
P FNC 

P FI  SE 

ni^'FN'TrN  v(#LLniTi*  fnkaldout),  pnzlalcclt) 

P OUTPUTf PNCUTl*# ) 

P OUTPUTf PNCUT2»«  ) 

wPiTF  (6»4eor) 

6CP0  FORHATdAHOFNTEPED  SFE»T) 

IP^FPX  - irPlCA 
T2SMYN  • TCPl'GA 

If  ( T2S FFX.FC.i J WRIT6lft/eOO»» 

60^5  FPPMATdYH'P  TIRE  »/) 

NOTH  • KTIH-IOC 
P TF  OAPR  • •YES*  THEN 

P 00 

LOCPAP  - LrCATEd) 

NXCAP  - CURVFL ICCCAB42 » 

NZPAP  • CURVE <LCCDAfl«3  I 
P END 

P !F  PAN  • ’•YES*  THEN 

on  I«TAPLT»IPCLT 

IF (I25FEY*f O.i)  VPirE(e»601C)TTMERIPtF 
601C  FCRHAYdF  »7Y.FiO*3L 

C CCPPI'TF  INITTAL  CL  T ANC  XLV — — 
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P IF  ISCUItC  - •FPA*  THEN 

KNiWPtIFlf  ■ XNIPPflfilF 

P ELSE  TF  ISOUtC  - •Cfi.ACCElEEOPElEP • TFEP 

>rN7WP«rpt.F  • XN7PPIBIF 

P El)f  IF  I50UFC  • •RAOAr*  Oil  ISOUFC  > •AIRSPEEO/AlllltDf  • 1PEN 

VN7WPtTetF  > XN7liTIIBUf 

CITT  - XM7WPfIB('F  PWUIBif  / (CB4RU1BIF  *!) 

VIVPIBDF  ■ XI  VC«CCTtlBlF  •CPCRO/IQO. 

TF  ( T?SFFX«EC*I)  WRT IE (6» 6C90 ) XL  V « I PUF 
FOW  FORFATIIF  .1PX,7BFCU1PIT  EY  SFEXT  XIV  •fFlO«9) 

P TF  AlCOFUr  <>  •NO*  CR  DAU  • •CL»RACN*Cr*  CR  OAEE  • '•HES*  1FEN 

P DC 

P TF  AlCOKUR  <>  'NO*  THEN 

AlFATtIRL'F  - AlFAPaieUF 

BFCTR  niRATTVE  inOP  FCR  CLY  CCNVtRCEFrt— — 


Cl  YP  > 

ITP  • 0 

f!  ITS  - T7F41 

P TF  OAPB  <>*NO*  THEN 

P OC 


-CAll  SDAPR  FPR  ALFA  CURRECTICN  DIE  TC  BTOF  PEHCIFC  ITAPf » 

IF  (Knapp.NF.O)  CALL  SCAPP 

* (PAPPtlBUFf  ALFAP«IPUF»OAHIIBLlF<CPART«lPUf>11PfllPLF«XMkP»I 

•»  BPLF.T  tABCCHf  CLA6.*  WBCCP*  CURVE*  XCAPP*  ICCEAP*  BXIAB*  BZCA 

4 P*irPL'rA) 

END 

ENS 

IF  AlOCKUP  > *NQ*  THEN  OC 

OUTPUTf*AlFATRlBUF  • ALFAPRIBUF*) 

TF  DAW  - •YES*  THEN  OUTFUTI*  • BAWfIBlJP*l 
IF  0A6B  <>  •NET*  THEN  OUTFUTf*  « OAlEflBtF'T 
OUTPUT  f«) 

IF  DAU  •>  •NO*  CR  OAQ  - •YES*  THEN 

DO 

-CALI  PALPR  FCk  ALFA  CORRECTICN  DUE  1C  UFVASF 

CAK  OALPR  (#IFAT«IBLF«  OALFARIBLF*  OACRIBL'Ff  0AI«1BIF»  APCTAIBUF* 
4 ALFAPRIBUF*  CGTtlBUF*  CLTI*  CABPAIPIF*  0 Akt IPLF > C • IB L F 

4 > TIPERIPUF*  VTTAIBUF*  XlVtlBLF*  1*  PFCAl*  PLCAL*  LDAC 

4 » ITRALF*CVALF»LCVALF*  LLCl R V » 1 C PLG4 ) 

END 

END 


-CAll  •NXNX  FOR  XN7kT  AND  XN7kP  

UTFX  - ? 

CAU  ^NXN7  ( ACCRA*  ACCNAP*ALFAT*CC1»CALFA*OAPtj*P»C»R»crCl»CR» 

4 XIVC*  CHCRT*  XNXP*  XNXPP*  XNTP*  XNZPF*  XNXW1*  XNZkl* 

4 INDEX*  JAXIS*  I*  XNTWR*  lESRXN  I 

Figurt  C-1 
FCF  FOR  LINK4 
(page  30  of  41) 


C-31 


P 

P 


O o 


r— — IF  rn  is  re  Bt  ccRRfCiEP  ftp#  cc^flie  cli 


P IF  NCOE.EXISTSflI»lK4«CCNSTANTS«IIECOf(fl1C.CLI  TI<EN 

p re 

P 0U1PUTf«Cl1I  - (XNZItTfIBUF  * VTfietf'*! 

P IF  VnUECUFTASfTPRVSI)  • MES*  THEP 

P QUTPUTO  > FftIfIBUF  ♦ SIN f ALfntlBtF  * XIFM1 

P OUIFl}T(‘«II(QBABTfIBUF  « Sl*»f) 

P ENC 

P IF  AlCONtP  <»  ‘NO*  1HEN 

P DC 

C .......... .... 

r FOIP  riPENSTCNAl  CCRVE  LCCKLF  ••  ALfAT  ■ F (APCT»C11*C€I ) 


PAtl  Fri'RO  ( AIFAT«1BLF«CITI>  APCT«I  eiF»CCl«ietF»LlCtFV»Cl>>VE(l  (C)  > 
♦ NDTP>KFALF»KLALF#TIM£«IPLf»5H5FI>T»l»KlPVl) 

P ENC 

P If  ALCOKUP  <>  •NO*  CR  CAO  > •CL»PACH*C€*  CR  OAEE  • MES*  THEN 

P OC 

C — ---. — — ... — ............. — -. — 

c CHFCK  FCP  ClT  tCNVERGEFCC 


IF  ( APS(CITI-CLTF)*L1.CVCLTI  GC  IC  J60 
CITP  - CITI 

IF  (TTP.IT.ITPCITI  GC  TC  i5 


ClI  TTEPATICN  LIPII  HAS  BEEN  EACEECEC  WlTFCLT  rCKVfcRGENCE 


CV  - ABSCCITl-CnP) 

WRITE JA,fcl001  I*CVCLT»  ITRCLT»CV 

61'>0  FrPHAT(2?H<rEPPCP  IN  SFEXT.  CIT(»I?»22H)  CIC  NOT  CCNVERCE  IC  , 

♦ F8#*»3H  lN,i&»33H  ITERATICNS*  IT  CIC  CCNVEPGC  TC  » 

♦ Fe.7»lH.) 

P IE  CVCIT  • •lERNIHAU*  THEN 

P 00 

WPTTF(6*61C*) 

6109  FCPHAT(14X,2lHexECUT10N  TERPINATEO.) 

STCP 

P END 

P ELSE  CO 

WPTTr(6»A110  ) 

6llf  FnpHATf 14X,2AHCIT  WILL  BE  PECAICCL AlECI 
ALFATPIELF  - ALFAMPIEClF 
P ENC 

P IF  ISOORC  • •FPA*  THEN 

XN7  - XN7NPP1BLF 

P ELSE  IF  ISCURC  - •C6.ACCELERCPETER  • THEN 

XN7  ■ XMPPIBUF 

P E13E  IF  ISOURC  - 'RADAR*  OR  ISCURC  • •AIRSFf EOFALTITUOE  • THEN 

XN/  • XNIHTPIBCF 

Cl  IT.  XN7  *VTAIBUF  / (CBARTilBUF  • SI 
P END 

C ................................ 
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OOO 


c -C*(l  SN)fK7  FTP  XNXhT  AND  CCPPUTF  HEfCOT  AND  FEX1— — — — — — 

C— 

160  INTEX  . 1 

CAtl  SNXN7  (ACCMAt ACCNAP* ALFAT>CGT»CALFA»DAeP>P»C«P#CCC1#CP> 

4 XLVC>  CHCRC*  XNXF»  XNXHP>  XNZF*  XNZFP>  XNXNlf  XNZkT» 

4 TNDEXf  JAXIS*  1»  XNZWP*  I25NXN  ) 

HFIDOTAfPUF  • XNXVT*IBlF*VniIBUF 
FEXTiTBDF  ■ XNXVT»IBlF*b1«IBtF 
CLT*I»!'F  • CITI 


COPIPUTF  CCT  AND  FNT 


OUTPUT f<FNTiIBUF  • FOTAIBUF'I 
If  VAIUf (UFTASvTHRUSTI  - IMEN 

OUTfVT  C*  * cost ALf ATfIBUF  4 XIFI*) 

OUTfUTf*  - FETfIBiF*«Bl 
If  CO  • »coHfuie»  T»*eH 

CPTfIfUf  ■ (FNTflBUf  - fEXTAlBUFI  / CQFARItlBliF  • S» 


CDPPUTE  fNOA,  FNrT2»  TSFC»  SFCCRA»  SFCCRT*  ANC  ISFC 


FNnAflRtf  • FNTAIBUF  FDATAlfUF 
FNrT2#IFl;c  . fNlAIBUF  /OZTfIBUF 

SfrnPAAIBUF  ■ WFTAIBIF  / (TFATltIBtF*4£THETA  • FMAlEtFI 
SfCORTAIPUF  • WFTAIBLF  / ( THZTi IBUFf^ETHET I * FNIIIBIFI 
TSFCilBDF  ■ fcfTfIBUF  /(FGlflBlF  - FRTfIBlF) 

TF  (TZSf EX.EC.l ) WRITE (6*6190)  C CT • I6UF » A L F AT* I PL F » FE XT • IBl F 
6l90  FrR)»*T(19X»l  !HCITPUT  BT  SFE XT* 5X » AHCOT»* F10*5 »6 X*  6 FAIFA T«»  F 10*9» 
4 9X*«WFEXT-*F1C«2) 


?0C  CONTINUE 
NPA''S  • f 

IF  (NSG.EC#!)  NFASS  ■ 1 
P If  OAW  > '•NO*  then  00 

P ENTER(fASSl*IACUT*«l*) 

P EHTER(fASSl*IBOUT#**l*) 

P ENTER(VASS1»H0.**1*) 

P ENC 

P EL^E  ENnR(«ASSl«ND»VALUE(PASSl*LOBOff  )) 

CAIL  WTPCA?  (lUCtT*0*  V*TIPE*NC*1ACLT*I6CLT  *«LCCL'T*FM*fN2,NFASJ,J  ENC, 
4 NRSECT*NREP*REPARK*12SFEX) 


TF  ( T2SFEX.EC.1)  WRITE  (6* 6200  ) 

6?00  FORPATdTWOPFTURN  TO  CALLING  ROUTINE  FRCP  SFEXT) 

P IF  DAW  <>  •YES*  THEN 


RE  TURN 


P El^E  00 

P 0€lETEfPASSi»lA0LI) 

P 0€lfTfffASSl*lB0lTI 

P ENC 

P OELETffVASSlfNO) 

ENC 

P END  SfEXT 
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« 


f 


c 

c 

c 

c 

c 


p 

9 

C 

C 

C' 


p 

p 

p 

p 

c 

c 

c 


p 

p 

p 

p 

c 

c 

c 

p 

r 

c 

c 

p 

p 

p 

p 

p 

p 

f 

C' 

c 


c 


OAUPrt 

!:UP»ClTlfF  0<iliPP  (ALfAT#  CALfA,  CAC»  OAl# 

APCt*  ALFAPf  CCT>  CIT>  DABe»  CAW*  C»  TIPE*  VTT*  XIV>  II* 
K^nAt*  KLFAU*  LOAfl#  I1RALF*  CVALFf  ICVAIF*  IIC»  12CAI.P) 


— UPViA5H  AFD  PT1CH  RATE  CORRECTIONS  StERCLTfNE 

— TMTS  St'PRCUTINE  CAiCUlATES  THE  UfWASH  ANC  FITCH  RATE  CCRRECTICN! 

— TC  THP  ANCLF  Of  ATTACK  AND  A TRLE  bING  ANPIF  CF  ATTACK* 


CCKKGN  /SAVCAO/  KLRVl*  CVOAKAOJ) 
inCTCAl  10AC»ICVAIF 
ITR  • I 
NCIH  • ACC 

If  OAt  • 'AlfA*  OR  OAU  • aALFAwMCH*  THEN 
PC 


OAt  - F(AIFA)  CR  — DAL  • FfALFA*  APCTI 


tC  CAU  FCItrD(DAU*ALFAT*APCT*CLPY»LtC»CVDAL>NDlP*KFCALr*KFOAl»TIPE, 
« 5HDALPR* IlfKURVl  ) 

ENC 

E13E 

If  OAC  • «CL<»HACH*CC*  THEN 
DC 


OAU  • F (CLT»ANC»C6T> 


10  CAtL  FOl!FC  (rAU»CLT*AHCT»CGT»LtC#CVDAU»NDIP»KFCAL»KlCAL*TirE» 

« AHOAUFR* IlfKLRVl  I 

ENC 

ELSE  TF  OAU  <>  'NC*  THEN  PE3SA€€(1* ALf NASH  LCCKLf  lN%AtlC«l 
IF  OAC  - «VES*  THEN 
PC 


CCPPUTE  CAC 

OAC  - AT#N<  XIV  • C • CCSfALFAT)  /(VTT  - >IV  ♦ SIKfALFAll  * C)» 
ENC 

■CrKPtTF  TAIFA  AND  ALFAT- 


OUTPUTI«OALFA  • *1 

IF  OAt  <>  •NO*  THEN  OUTPUT (•PAL  • » 

If  PACE  <>  •NO*  THEN  OUTRUTI*  ♦ 0A8EM 
TF  OAb  <>  •NO*  THEN  OUTPUK*  « OAbM 
IF  OAO  <>  •NO*  THEN  OUTPUTI*  ♦ OAO«I 
OUTRUTftI 

ALFAT  • ALFAK  OALFA 


CHECK  FOR  CCNVEFGENCE  CF  ALFA 


IF  (ITR  .EG*  *)  GC  1C  6G 

I*  (AP<;<ALFAT  - ALFAP)  .LE*  CVALF)  GO  TC  9C 
IF  (TTR  .GE#  ITRALFI  GC  TC  TC 
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r>  r%  n 


c— — AlfA  HAS  NOT  CCNVfeRGEO  AND  ITERATICK  LlMl  ►AS  ►CT  B£EK  t>CtErcO  — 

60  A1  FAR  • At  FAT 
ITR  • TTR  ♦ 1 
f-n  TP  1C 


•ALFA  HAS  NPT  CCNVERGEO  ANC  ITERATICN  ITMT  HAS  PEEA  EACEEOEC 


70  WRITS  (6>6P7P)  II*  CVALF*  I1RALF 
6070  FnRRAT(23HOFRKCR  IN  TAlPR*  ALFA (« I2*22H  ) 
« FE.f^SH  IN»T5*i2H  ITERATICNS.I 

•USE.lASf.«ALUE*  IHER 


010  NC7  CONVERGE  TC  * 


IF 


»*2€H  WHICH  CCNVERGEO  1C  •F8*S* 


LCHAIF 
DC 

''TTR  • AIFAT  - AIFAP 
WRTTF  (6.607*)  II.  AIFAT*  CIIR 
6079  FnRHAT(l«V»«HALFA(*I2*AH)  > •F6. 

« lAH  WILL  BE  USEC*) 

ENC 

ELSE  IF  ICVAIF  • •RECOFFUTE*  THEN  OC 
If  OAW  <>  «NC«  AFO  OAEB  <>  RFC*  THEN 

OC 

01ITFU1(*0ALFA«»*>*I 
IF  OABB  <>  «NC*  THEN  CUT  FIJI  (•  OAF  C • ) 

IF  DAW  <>  RFO*  1HEF  OUTPUT  (•  * CAti*l 
OUTFUT(t) 

CFO 
ELSE 
r>A(RA  > €• 

Al  FAT  - AIF AH  ♦ CALF  A 
WRlTF(6,6Cfc(0) 

60B0  FPRHATl  107-.  36HAI  f AT 
R EFC 

R ELSE  FESSACSCI* *isDAUFF  ALFA  NC-CONVCFCENCE  FLAC 


• ALFAR^PAW^CAEB  Wilt  RE  (SEC«) 


INVALID*! 


•PRINT  'tFCnNOART  CtTPLT  ANO  RETURN* 


<0  IF  ( I20AI r.FC.l  I WRI TE  (6 . 6000  ) DAL.CAO.ITR 
60RC  rrsf-ATtlH  .IRX.iOHCUTPLT  EV  CALPR  CAL 


RE  THRN 
FNF 

END 


Mt(»**9X.ieHAlFAT  CCNVERGEO 


CAL'FR 


■*)IC.!*9>.5FCAC 
1N,14,12F  TTEFATICNS.) 
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p soAtri 

SUPI»rL'TIfT  SPAPP  COAPB>  ALfAP*  OAti*  GBAPl*  TIPE*  X».ZbFr  11* 

* APCCP*  CLAB*  WPCCP*  CLPVE*  KCABP*  ICCCAB#  K>CAe*  KZCAB* 

♦ T2SPAP) 


Bnr»*  PENriNr  rcppECTiop  siprcitike 

T»*T^  Sl'PPPUTlNE  CCHfUTES  THE  AEPCOTHAPIC  AHC  IHEPTlAl  LCACS  CK 
THE  BOCP  AWr  A CCPRECTICN  TC  THE  AHGIE  OE  ATTACK  Clt  TC  THQ^E 
t CAPS. 


OIPEN^IfK  rUPVEfE) 

AIFAV  • ALFAP  4 CAK 

FB  • OPAPT  • ABCCP  • ClAB  * ALFAV  4 XNZVP  * VECCP 


TAPIE  irCKl'P  ••  CA6B  • FfFPI 


CAll  TAPFKT  (FB*CABB»0*»KADAE»NZOAP»CURVE(irCCAe47)*lKClC  * 

4 TlPE*9H5DAee*l*lI*KDAPE) 

IF  ri?5PAA  •FO«  1)  HPrUI«»600Q)  OABBfFB 
AOOC  FORHATdH  » 1 FX  *&6HCUT  PIT  ET  SCAttP  PABE  • *F1«  .5  *3  > F FB  ■> 

4 Flow'd 

RE  TtlPN 

Fwr 

P END  TOABf 


1 


i 

1 
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! 





liTirmrrxnm. 


P SNVNn 

Slirtn  TI»iE  SK'XNZ  <ACCMI»ACCKAP»*LPHA»CCT«OA*C«ee>CeAM(*CTt-ET*CYA  V r 
« D2THET»GI)»  XLVO»  Xf^Af*  XNXX>)'NXrP*XNZP»XXZXF>XKXW> 

4 XNZta«lNOEX» JAX1S>I>XNZVF»JPIG3  ) 


C.....LrAn  FAflrX  caicliations  sippcuunc 

c — T*-I*  ?I.PBrL'TINf  CCMPUTES  CCERECTED  VAllES  fCP  hCFFAl  AKC  FLIGHT 

C— — PATM  IfAW  FACTCPS*  PEASUPEC  VALLE3  CF  NX  ANC  N'Z  AFe  PCTATEO 
r— — T».aoUGH  the  PEOUIPEC  ancles  and  TRANSLATEC  PETfcEEN  ECCP  ANO  CG 
C— — AS  NFCF*5APT. 


C 

C 

c 


c 

r 

r 


c 

p 

p 

c 

c 

c 


p 

p 

p 

c 

c 

c 


OrPEN«ICF  At  PHACl)*CCT(l)»OA(l  ItOAESdNCEAFKII  )> 

« rT»-ETr.)»0YAWIi)«D2THET(ll»  XNXp  (i ) , XN  XP  F ( 1 ) » 

4 XNZH(l)#XN?nP(l  )»XNZV(ldXNXH(l  )>XKZVF(1  ) 

LPAD  FACTOR  C ALGOL  AT ICKS 

XI  VI  • XLVO  4 CGTXieUF  * XPAC/l;j0«O 

HNXP  • fXlVl  /GR»  ♦ (lOTHETXIBUf  ♦•24  CYAWAIELF  ••  2)  ♦ CCS 
4 (At  PHAfPieOF)  - (DEANKilBLF  • OTAVPTPUF  - tZTHETUELF)  ♦ 

4 STH(ALFHA«IBLFn 

ON7P  - (XLVl  /GR»  • ((DTHETAIBLF  ••  2 4 CYAVXIPLF  ♦•  2)  ♦ 

4 SIN( Al PHAAIBLF ) 4 (CBANKtlELF  ♦ CYAk«lBLF  > DZlFETAIPlFt 

4 • CC5(Al FHAPIBLF  ) ) 

Chpck  JFIP3-1  TO  SEc  IF  NFCESSARY  IC  PRINT  SECONOAPY  CLTFLT 

TF  (JFLG3  .FC.  1)  HPITE(C«38)  OFXP*  ONZF 
3P  FCPPATdH  ,1PX»26HCUTPLT  PY  SNXNZ  CNXF  •»  F*C  • 5 » 3 X FCN  Z P « » 

4 FIO.^I 

IF  JAXIS  • ••I*  THEN 
DO 

JAXIS-1 

IF  (TNPFX  •EG,  2)  GC  TC  5C 

XNXWP  • XNYPFPIPUF  ♦ CCSCCAITBL'F  - CABPAIPLF  4 ACCPAF)  - 
4 XNZPPiieUF  ♦ SlNCCAilBLF  - CARBfTBLF  4 ACCPAFI 

XNXWiTBOF-XKXWP  4 DNXP 

IF  (TNOfX  *EC,  1)  GC  TC  99 

5C  XNZWPPIPLF  ■ XNXPPAIPUF  ♦ SIK(CA«IBLF  - OAPPPIPIF  4 ACCPAF)  4 
4 XNZPFilBUF  ♦ CCSIDAPIPLF  - TAPEXIPIF  4 ACCPAF) 

XHZWPIPOF  ■ yNZVPPIBLF  4 CNZF 

ENC 

ELSE  IF  JAXIS  - •Z*  THEN 

DC 

JAXTS-P 

IF  (TNOFX  .FC*  2)  GC  TC 

XNXWtTROF.YNXPlIRUF  ♦ CCS ( AL PH A# I BLF  4 ACCPA)  - 
4 VNZNXIPIF  ♦ 5IN(ALPHA«IBLF  4 ACCPA) 

TF  (TNOFX  .EC*  1)  GC  TC  99 
5J  XNZWPIRUF-XNXHPIBOF  • SIN (AL PHAPl BtF  ♦ ACCPA) 
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E 


P 

P 

P 

C 

c 

c 


p 

p 

p 

c 

c 

r 


i 

P 
p 
p 

c 
c 
r 


p 

p 

p 

c 

c 

c 


♦ ♦ JtNZHtieUf  ♦ CC5  (4lPH4iIBLF  « tCCPP) 
VNZwf'tTBlF  • XNZWtlBLF  - CNZF 

ENC 

fl?f  If  JAXIS  • THIH 

oc 

JA1TS-1 

TF  (Tkpf>  ,pc.  H GC  1C 

xrZWFT«l'F«  (yKZPFTBUF  ♦ XKXVIIBCF  • S IN  ( Al  • lei  F 4 
« ACCPAI)  /COSiALPNAAIBLF  « ACCPA) 

XNZWPtTBLF  • XF.2V«IBLF  - CNZF 
FHC 

F13E  IF  JAXIS  • 'A*  THEN 
OC 

JAXIS-A 

TF  (INOFX  .FC,  2)  GC  1C  *2 

XNXWilPl'F.fXNXPAIBUF  - XNZWflBUF  • S IN  ( AL  FFAtlBC  F 4 

♦ AfCPA  n/COS(ALFFA*lPtF  ♦ ACCPAI 
IF  (TNOEX  ,tC«  II  GC  1C  9A 

92  XNZWP*TPIF  • XNZktlBlF  - CNZF 
ENC 

EISE  IE  JAXIS  • *9*  THEN 
OC 

J X »I ^*9 

TF  (Uncx  ,FO,  i)  GC  TC  AA 

XNZW»«TPVF  • (XNZFPIIBCF  ♦ tXNXIitlPLF  - CNXF)  * !lh 

♦ (OAtIPUF  - OAPBtlBUF  •»  ArCNAFII/ 

♦ CC5(OA«IBCF  - CABBAIBLF  -»  ACCPAFI 
XNZHfTBlIF  ■ XNZVPAIBCF  ♦ CFZP 

EHC 

ELSE  If  JAXIS  • •B*  THEN 
OC 

JAXls-6 

IF  <»NP£X  ,fC*  2)  GC  TC  53 

XNXWP  ■ IXNXPPflBUF  - (XNZkilBCF  - CNZF)  • JU 
4 (CAtlBlF  - CAPBAIBIF  * ACCPAF))/ 

♦ CrSTOA  IBIF  - OABP  I»»LF  * ACCPAF) 

XNXbFTBCF  - XMXVP  • CNXP 

TF  (INPf*  .FC*  1)  GC  TC  AA 
9J  XNZWPfTBIF  • XNZNAIBIF  - CNZF 
ENO 

ELSE  IF  JAXIS  - THEN 


JAXIS-7 

HFSSAFECl9*NaNO  ECUATION  TIT  FOR  ORTAJSOIRCE  > T**! 

i 

Figure  C-1  j 
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JINJIWO  • 

P eiSE  IE  JEXIS  • •••  thin 

P oc 

c 

C JA)I1S"« 

c 

P HfSSACE  fl»*W«N0  fOlATlOHS  VET  PCR  OATA.SCURCE  • EM 

XN7WP  • 

P EMC 

P EHE  IF  AAAIS  • •E*  THIH 

P DC 

C 

C JA>IS*fl 

C 

TC  (»N0E>  .FO.  1)  GC  1C 
XN7W»FIBI.F  • XMZkllBtF  •>  CN7F 
P EHC 

99  BFTI'ON 
FNT 

P END  SNAHI 


P OAlACt 

OVPPIAY  (SFfyT>^»2t 
PRCCBAM  CAIAC 

r— OYMAKIC  IA6  CCRPtCTICN  StCOKDABY  CVEBIAY 

C T*-T5  PBCCBAP  CCHPITCS  THE  OTNAMIC  lAG  CCARECTIC^S  1C  IHE  ANGIE  tF 

C — attack  ICAWU 

P OUTFUTfCOHlNvf  I 

P OUT»l'T(CONOUTtfl 

•CCHCL'P^E 

P 0UTFUTfC0NL4»f I 

niKEN^TCN  AtFAVl  tlOlN*  ACCNF  •ICIP>  ACCCF  tlCTP*  ALFAV  IlCIK* 

« Al'AV?  KIOTN,  Oil  AIOiK 

WPltF  (A,6C0C} 

AOOe  POBHAT(14HOFNTEFEO  OAIAG*//) 

P If  ffEO  <>  •CCHFOTE*  CF 

P DPPP  <>  •CONFUTE*  THEN 

F OC 

C .................. 

c--. — pcepApf  pro  CURVE  iockip----- 

c 

F IF  fREO  > •CURVE*  THEN 

F CC 

LOrw  - ICCATFU) 

NYv  • ripvp  (icrv*^) 

N7V  • CU«VF(ICCV*3) 

F EHO 

F If  OANF  • *CURVE*  THEN 

F DC 

lorr  • ircATF(2) 

NY  7 . C»  BVE ( I CC7*2  ) 

N77  • ri'PVE accz^a ) 

F END 

F ENC 

c ..... 

c -PREPARE  FCP  rif FERtNTI ATICN- 


C 

MFP  ■ HF 
MPK  • 

TNPTS  • KFK 
NC  - 0 

c 


c— FREH  NER*  Tc  50.  IMHAL17E  ALFAV  AND  ALFAVl.  AKC  CCFFl'lE 

C ACCKF  AND  ACCOR  


C 

OC  50  T«1.1PTN 
At  FAVd  ) - -R994* 
Al  FAVK  I ) ■ ir.o 
C 


c-.— CCKPUTE  ircNF  — — 

C — — 

F If  fREO  • •CCNFOTE*  THEN 

ACCNfm  • TORT  (CFART II  l•AVANE•Vl•CLAV/)>IYY) 
F EISE  CO 
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r>  <rt  oor>  ->oo  ooo  r>r»r»^ 


Nf  • KC  ♦ 1 

CAIL  TfPFNT  ( AKCTCII*  ACCKF(T)*  CGARTfl)*  K?k»  CLFVF  (I C(k«  n 

« •IKDIC*  TlPE(l)#  9HPALAC*  NC*  I*  KWFV  ) 

ENC 


CCt'PUTE  ACCDP 


If  OAff  • «C0flfUTE*  THEN 

ACCDRd)  > XI  * ACCNF(n/(2«0  * VTT(I)) 

EITE  CC 

NC  • Nr  « 1 

CALL  TARENT  ( ANCTIDf  ACCORID#  CBARTII)*  NX2,KZZ»  CL  R NE  ( L CC  2 1 > 

« INOIC*  TlfECD#  9HOAIAG*  Nfy  Ip  KZV  ) 

END 

90  CrNTINUF 


-CONPUTf  ALFAV 


ITP  • 1 
6C  jrATR  • C 

on  7^  I-1>1PIN 
AI^AVT  • AlfAVin 

ALFAV(T)  • lALFANZd)  * 2«*  A CCOR  ( I )«  ACCNf  d I AL  F A F 1 d )- Al  F A V ] ( I } ) 
♦ ♦ArCNFd»**2AALFAf'd»»  / < XKT*  ACCN  F (I ) * <2  ) 

IF  (T.iT.TAri'T  .CR*  I.CT.IPCLT)  GC  U 70 
IF  (A»»SIAlTAVd)-AtFAVT».lE#CVOAW)  JCNTR  ■ JCNTR  + l 
7C  CCNTIRUE 


CHFCK  FCP  CONVERGENCE  CF  AIFAV 


IF  (TTR,F0*1)  GC  TC  75 

PfTrV  - inO«AFLCAT(JCN7R)/FLCATdBCLT-IAClT«l  ) 
IF  (PCTrv.CF.PCTOAVl  GC  TC  SiO 
If  ( TTR,CE*TTRCAW)  GC  TO  EO 


COPPUTF  ALFAVl  ANC  Gt  EACP  TO  60  FCR  ANCThtP  ITFRATlCN 


7*  INDCR  • ] 

IPIF2-P 

CALI  niFFRdIFiE»ALFAV»IC>PF,PO»HFP«PBH>IKCCF»INFTS*SCIF*IPlN*CLl» 
* AlFAVi»ALFAV2»5HALFAVdCIF2>r5PA,NANC«) 

ITP  ■ ITP^l 
GP  TC  fC 


Al FAV  OTT  NCT  CONVERGE 


Pr  WRIT«l6>e080)  PCTDANfCVOAV* ITRDAU* FCTCV 

80  FORPATI IPHOFRRCP  IN  DAIAG*  >F8«3»28F  PERCENT  CF  ALFAV  CTO  NCI  CC* 
* lOMNVFRGE  TC  *F8«5*3H  IN>I9»12H  IT f P AT  I CN 5«# /* 17 X* F E« 3 > 

4 92H  PERCENT  DIO  CONVERGE.  CLRRENT  VALLES  VILL  EE  L5ED.) 


CCPPUTE  CAW 


<J0  HP  r-IACLT>IBClJT 
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r 


nAWdI  ■ AtTAVi  n-ALrAPC  1 I 
IOC  CONTINUE 


c — SECONPABT  OUTPUT 


TP  (TPBLCA.NE.l)  GC  TC  20€ 

WB  ITE(6»E1N0)  PCTCV»ITii 

6150  POBFATflP  «TlrX»F7.2»31P  PERCENT  CP  ALFAV  (CKVERCEC  IN  pU» 

♦ 12N  TTEPATICN5*) 

WRITP(6»A160) 

6160  FnBNAT(lPC,I2X»  AHTIHE*  lOX  ORAL F A V * lOX »6HAl  F A V1»  1€  X#9h ACCNF*  1 1'>«^ 

« ■FACrOR*  9X»5FALFAP>10X»6HAiFANl»  <!  X *6F  AL  F A P2  I 

WR 1TF<6«  E161  ) 

6161  FORNATI IN  >11X»6H<5ECS i»7X«9N (RAO/SEC l> 6 X*9F (RAC/5EC  U6X»6F (RAC/ 

« 3NEC)»6X>'AH(RA0/SEC)»TX>5F(RA0)»9X»9F(RAC/5EC)»A>*6F(RAC/!* 

♦ 6FEC«*2)>//) 

WR  ITP (6*6170)  (TINE ( 11* ALFAV (I )>  At F A VI ( I ) » ACC NF ( I )*ACCCR(I  )* 

4 ALFAN(n#ALFANl(I)*ALFAN2(n«r-lACLT*IECtT  ) 

617C  FCRNAT  ( (Ny,80X*F12«5  ))  ) 

WR TTF (6»6T60  ) 

WPTTF(6,6162) 

6162  format (IN  9T1X*6H(SECS )*7X*9H(0EG/SEC)>6X»9F(CEG/^EC)*6>>6H(CEG/!> 

4 3FFC)*6X»9N(0EG/SiC)»7X>9N(CEG)»9X*9F(CEG/SEC)oAX*6N(CEC/S» 

4 6FEC**2)*//) 

RAF  . 67*2957 
00  TOO  T.IArLT»IPCLT 
AV  > ALFAV  (I)  * RAC 

AVI  - Al FAV1  (I  ) • RAC  < 

ANF  - ACCNF  (I)  ♦ RAC 
ACR  • ACCOR  (I)  • RAC 
AN  - Al  FAN  (I  ) * RAC 
ANl  - ALFANl  (I  ) * RAC 
AN?  - A1FAN2(I)  * RAC 

WRfTF(6,6T'rO)  TINECI  )»AV*AV1*ANF»ACR*AN*AP1»APC 
190  CONTTNIIF 

WRIT? (6.6190 ) 

619C  FPRNATdINOEXI  1 CAIAC) 

70e  CONTiriE 
FNC 

R ENO  OAtAC 
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CVF»<LAY(  SFfcXT,  4,0) 
PRC6PAK  L1NK4 


PcPFCaPANCL  ItST  C3N01T1CKS  PRIMARY  OVERLAY 

this  "kcgrap  controls  calculation  jf  Tksf  pekfopmance  parameters. 

iTi  ONLY  FUNClltiN  li  Tt  CALL  I'JTO  iXECOTIuri  Iric  SUBROOTiNtS 

1NPLT4  AND  SFEXT. 


PRIMARY  OVERLAY 
.ULaTION  jf  IfeSf  PEkFLPMANCE 
ALL  1410  iXECoTiuN  Inc  SUBROOTiNtS 


parameter; 


COprCN  /ALL/LUIN»LLUL1,LLC!JRV,LThRtS»S»XIf,CH0RD 

COMMON  /L4CATA/  CV  ALF,  CVCLT,CVOAN,  il)BUG4#I0,  I3M4,ITPALF,  ITRCLT»ITR 
IDAV,  K0ABR,KFALF,KLALF,  KWnV 
CLMMCN  /L4CAIA/  OZ  VMB,  MB  ,MF,  NANC  4,  PC  10AW,SDI  F 
CoMKCN  /LlCATA/  ZUC,  NDFLAG 


CLPMCN  /L4INTK/  NR lM, k EM AR K ( ) , NR Sc CT ,NSG , J cN J 

NSf  « 0 

WRIT?  (6,6CUC) 

''O'tn  format  {14HjkNTEAcD  liNK4) 

CALL  INOCTA 

IF  ( J?NO  .FQ*  i)  C-n  TC  R***? 

CALL  SFFXT 
CO  TC  ly 

oa^  VP  ITM  e,  6R49  ) 

,,paq  FOPMAKaIHCFXIT  L1HK4  ) 

ENP 


Figure  C-2 
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sue^iruUNF  iNPcT<- 

r-- — -riNKZ”fTLT"TKPtT’IccrNclRY  SUBROLT  »nE 

f — fH5  PROr.RAt^  LC*DS  MtC-tD  CblVci  FROM  A CtRVc  FILE  INIL  CORt  ANO 

f Pt^cs  ^A^AniTlk'  fkOH  AK  INPUT  b ^lLt•  THkife  CURVES  AND  3 Flic 

r FIRAIrTvK  VAlUtS  ARfe  THFN  FaSScO  IJ  TH€  QTHFk  LInKA  SUBROUTlNt 

f THPruGH  CCMFCA  Blocks  for  pruCc-sing. 


LP-MLN  /All/  lLlK.lUCUT.LUCUkVelHRUS»S/XIF#Cr)0«D 
CUPFCN  /L^.IATA/  CV  Al  F#  CV  Cl  1«  CVDa  k#  iO  BUC-A#  I C#  IS  HA,  1 T 
lPAW»KOAP>'’»Kf  ALF»KlAIF»KWNV 
CCMMCN  /lACATA/  DZVMB«M6#nF#NANCA»PC10AW#$UlF 
CrHMCN  /LltATA/  2UD#  NCFLAC 


half# ITRCLTflTR 


rrMMCN  /LA  IN/  11Mfe>AlFAN*Ar.CT>  DAT#  D2T#CGT*  FcT#  FG1#  FRT#  P#  0#  0C0T*CBA 
IRT  ,P  ,rHAT»TH2T»VlT»NFT#XNXM,  XNZM#8ETA»GANA2,  GAHA3 
CCF'TN  /LACUT/AIFAT»CL  (»  FgXT#FNDA,  FNDI2#  FNT#  He  TOOT # S FCUR A.  SFCORT# 
ITSFC  *XKZWTP>  XNZWT#  XNXWT#  COT*  DA  IF  A#  Oc  it  A#  ZETA*0HECA 


*.  n 


r_ 


CClFMCN  /LAInTR/  NRcM*RENARK(XU)*NRShCT»NSG»JfcNt) 

DIMENSION  FN1(22)*  PK2(22I*  VAL(22)*  TM(200»» 

1 TN2(2C0)»  LISTNr{200)»  V(200)»  NUH(22) 

E01IVAL6NCF  (VAUl  )*  AIFAM) 

DATA  PM  /5  HA  If  AM  .AHAFCl*  3H0AT*  3MD21#  3HCGT*  SHFcT#  3HFGT*  3HFRT*  1HP*1H 
iC,  AHtDCT»;>HOFAFl  »ImR.AhTHAT»  AHU  2T  * J HV  1 T * 3 HW  FT  » A HX  NXH,  AH  XN  XM*  A HB  cT 


2 A*  AH(  aMA*APGAMA/ 

tat*  ONP/IP  *AH  TkO*t>H  TMRtF/ 

F'VAP  -22 


► L :p  » louc 
NSf  ■ ^SG  * 1 
pPi'T  (h»6ri>0) 

FTFHAT  fl>hUl-NnRfr  iNPUTt*//) 
IF  ( •‘'G  .ol*  1 ) r-L  TC  200 


— PPIM  INPUTS 


^ V.K  IT  I ( t*  6101  ) LUlN*LtUuT»LLCURV*  LImHLS*3»XIP»CHUPC 
MP'‘fcT(6X.  iPHPACAMTIRj  FPPM  COMMON  BLOCK  ALL*/* 
il'’''i7HUTN  »*  I‘  , lOX,  THLUG'JT  ■»  IS  » / » 10  X,  ThLUCO  P V ■*  I'j 

2iOX,  /HLTHRl  >-*  Lt  »/»10X»7HS  •.  ti  A<  6#  /»  i 0 X » 7H  ) I f ■#£lA,6»/» 

3K>,7<CHnRr  -,ElA.o,/) 

<6*61)2)  CVALF*CVCLT»CVoA-<*iUBUCA,  IJ,ISMA,  1TPALP»1TKCLT, 

1 n PC  AO .KOABBfKF ALf *K  FC AU»K  LALF  *K  LOAU»KVNV*  K2 V*  Mp,nf, NANC A* 

2f  C IfiAUtSDI  F 

^,irvp  r^P'-AKoX,  3SH<  aPAMIFPo  FROM  COMFuN  BLOCK  LAOaIA*/* 

1I0X*7HCVAIF  «*  t)  A,  6, /.  lOX.  7HCVCL  1 •*  fcl  A,  6* /*  10  X,  7HCV0Ah  ■*clA»6»/, 

2 E 1%*  (.  . /*  lOX  . 7H  10  BliGfH*  IS  »/**OX»7Hi0  ■*  Ij  ,/* 

MJX,7HI2*'  -fi*!  */»10X, 

<.  ii'X.  73’tBALr  ■*  Is  . /»  ICX.  7MI»  RCir»»  is  * /*  10X*7HnR0*.W»*  iS  ./* 

5 lOX. /*  lOX*  /HKD  aB  P •*  IS  ./. 

6 lOX  , 7-<kF  AL  F •*it  * /*  aOX*  7HKf  DAL  •tij  . /*  10  X , /HK  L AL  F -.IS  */* 

7i(.iX,  T^KlOAI  -,I‘,  , /*  lOX*  7HKWNV  •fib  »y*10X,7HKZV  -.IS  ./. 

B /»  lex,  7H*'B  I‘-  »/.  lOX.  /HMF  -,16  * /. 

010X»7HMnCA  -,I'  ♦ /,  lux.  /HNRLMA  ■*  IC  » /,  10  a*  7HPCT0AW**  tl ‘.,0, /* 

0 lO  . 7 < P.)  IP  ■*  lI  ^ ) 


k.-LlNT  LOIN 
PtViNO  lLOLF 


PF/O  Lk^UT  8 FILE  LABcL  RECJRU 


F'AC  (LUTS)  L»NRStCT»NRtM»  (REMARK!  l)*I»l»SRcM)  * M AB*  ( TNK  I)  * 
1 TN2(I  ).L1STNQ(I).  I*1»NLAB  ) 

CALI  LABSOP  (PNl*?N2»TM»TN2*LlSlNb»NUM»NVAR*l.NLAB) 


r C-TkRhihc  NccDfcC  PARAMcTE^^aRE  AVAKABLc— — - 

Du  ISO  I»1,mVAR 

IF  {NUM(  1)»GT.0)  go  1U  130 

r NFtCBC  “ARAMETFR  NOT  AVAILABLE — 

TAO  WP  6*  61  AO  ) PNKD*  PNZd) 

KIAO  FnRM/r(20H  ERROR  IN  (INKA*  PAKAMtTER  *2A6*lbH  NCI  AVAlLABle  JN  * 
1 13HINPUT  B FILE,) 

IGC  « 0 


r-  — — IF  AKY  ERRCRi  WERE  E KC 01. NT f « iO * SeT  N0FLAG>3  AND  RETURN 
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'SO  If  f!GC  acC,  0)  ►fOFLAG  • i 
IF  ( TGC  «lc«  01  GO  TO  260 


RR/ip  VALLES  FDR  PARArETfeRS- 


90C  R~AD  (LUIN)  t*  (V(J)>  J«1»N) 
IF  (F  aNta  U)  60  TO  270 

rz  • 0 

Z • C 

WRITf(  LUnUl)  IZ.Z»Z 
PA''  JFKP  ■ 1 
'^''0  RFTI’pm 

FNT 
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fl"<or'niNe  SI-fXT 


ThI 


T..^T  -XCtS^  THRUST  StcCNOARY  JVsRlaY 
ThIj  ji;CQRjARY  OV6RLAY  COHPCT6S  THE 


..  ..  S The  BLJh  BtNOlNG#  UPWASH  ANt 

PIlCH  PATT  CORPfcCTICNS  TO  Th*:  AHGLc  OF  ATTACK  ( CABB/OAU»DAO ), 
TRUf  ANGLF  LF  aTTACK  (ALFAt)>  LUAD  FACTORS  (XNX.XK?)#  LIFT 
CrcfFICT-MS  <Cll»CCfT)t  RATt  OF  ChAHGt  OF  LKcRGY  HclGHl  (HcTD'JV) 
AFC  feXCESs  THRUST  (FcXT)  FOP  TEST  CONOITIuNS.  IT  THEN  WRlTti  THEI 
UN  THE  OUTPUT  P FiLE# 


COFHtN  /ALL/  LUIN.LULU’t«LUCURV>LTHRUS»S*XIF#CHORr 
COPHLN  /LADATA/  CVALF»  CVCLT*  CV0AW«I0BUG4#ZG#  ISNA«1TRALF»  ITRCLTaXTR 
ICAk,  KJABB>  KFaLF»KL  ALF#  KWNV 
Cu^NC^  /LACATa/  02VHB#NB#HF,NANCA/PCTDAW/SDJF 


CvJPHlN  /LAIN/  TINE  »ALFAN*ANCT»  DAT»  02T*  CGT»F£T#  FGT#  FRT#  P«  Q*  GDOTfUBA 
IFT  >P  *THaT*1HXT»VTT*WFT»XNXH>  XNZN^dcTAf  GaNAZ#  GANA3 
LOPHCH  /LACUT/Al  FaT«CLT«  FtXl  »FNJA»  FN0T2»  FNT»  Hfe  ) DCT  >S  FCCR  A#  SF  CURT  » 

1 TS  FC  # Y NZ  NT  P»  XN  2W  T#  XN  Xh  t#  CO  T,  OA  Lf  A«  OE  LT  A#  Ze TA  * ONE  GA 

COPHCN  /LAIN1R/  NRfcri>RENARK(  10  )#  NRSeCT»NSG>JtHO 
OIFFNSIJN  V(18)#  PNl(lA)*  PNZdE) 

DATA  PNI/SHALF  aT»3HCL1  »AHFEXT»  AHFNOA»5HFNDT2f3HFNT*6HHeTDOT»6HSFCCi 
lRAf6HSFC0RT«  AHTSFC>6HXN7WTP#  5HXNZwT>  $HXNXWT»  3HCCT>  SHOaLFA#  9HD£LTA« 
2AHZtTA#5HnHFCA/ 

DATA  PN2/IH  #17A1H  / 

WPITt  (6#600C) 

FORMAT  (lAHCIFTEPeD  S Ffc  XT  ) 

T2SFEY  • ueirA 
izSNXN  ■ icaiGA 

IF  ( I2SFEX,F0,1)  WRITE  (6»6C05) 

FrpMAT(l7H0  TIME  » f) 

• K DIP-LDC 

IF  (T2SFcX«FQ«l  ) WR  ITE  ( 6>  60 10  ) T IH  E 
6/''»C  PORMATdH  »7X»F1C»3) 

• COMPtri  INITIAL  CLT  and  XLV 


XNZWP«  XNZM 

CLTI  - XNZUPAWT/  (CBARTPS) 

XLV«  XLVC-»rGT*CNCRD/ JOO* 

IF  ( IZSFEX.bC.l)  WRIJt  (6,6050)  XLV 
FniJMATdH  ,ifcX,26H0UiPUT  BY  SFEXT 
alfat»  alp  ah 


•tall  snxnz  flk  xnzwt  and  XNZW*' 


>»F  10#5  ) 


TNDPV  » 2 

Call  snxnz  ( ACCHA,  ACCMAR,ALFAT,CGT,0ALFA,0ABB,  p,  c,  r,odgt,gr, 

1 XLVn,  CHORD,  XNXH,  XKXHP,  Xi^ZH,  XNZHF,  XNXWT,  XNZWT, 

2 INDEX,  JAXIS,  I,  XNZWP,  12SNXN  ) 


ir  CLT  IS  TO  Bt  COkkECTEO  FUR,  CCMRUTE  CLT __ 

CLt”*«”7xnZwT*”wt”-”fGT*  SInTaLF ATH”xlFTT7TaBZKT*  sT 


NXNZ  FCR  XNXWT  AND  CCHHUIE  HcTDCT  AND  FtXT— — ' 


UP  INDFX  ■ 1 

CALI  SNXNZ  (ACCHA,ACCNAP*ALFAr,CGT,DALFA,DAtt6,  P,C,R,QDCT,GR, 

1 XLVO,  CHORD,  XNXH,  XNXHR,  XNZN,  XnZHP,  XNXWT,  XNZWT, 

2 INOfy,  JAXIS,  1,  XNZWP,  I2SNXN  ) 

H'-TDuT-  XN>wf*VTT 

FEXT-  XNXWTAwT 
CLT-  CLTI 


CCHPuTc  COT  and  FNT  — — 


FNl-  FGT  • CCS(ALFAT'»  XIF)  - F£T 


■CCMdjTc  FNDA,  FM'T2,  ISFC,  SFCJRA,  sFCORT,  AND  TSFC- 


FNCA-  FNT/CaT 
FnCTZ-  FMT/D2T 

SFCHRA-  HFl/ (THAT**ETHETA  ♦ FHT) 
SFCL'RT-  WFT/CTH2TPAcTHFTA  • FnT) 


(IHZTPAcTHFTA  • FNl 
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MO" 


IF  ( T?Sr  bX«tO*i)  WklTE  (6.01-9C)  C bT#ALFAT*FfcX  I 

FuKr  AT(l9X,liHUL;TFUt  BY  SF|XT»  5X»^HC0T»#  F10«i»»  oX#6HAlf  AT-/  FiO.S/ 
I 5X,  5^F*;XT■»  F10*2) 

fnMHlF 
^"AS5  • 0 

IF  (^^G,E0.1)  NPASi  • 1 

CALL  MTBOAM  LL  CilTfO*  V*  TIME  FNl*  PM2>  NPAbS> 

IFND/  :>:CT#NRE  H/ REMARK  , I 25 FcX) 

IF  ( I.?«F£X-:C,ji)  WRITE  (6#620C) 

Format  OTHCRcTURN  Ta  CALLING  RUJTIr«t  FROM  5F  EX  1 ) 

R-TURN 

ENP 


-LOAD  F-ACTQR  CALCI'L  ATlOh^  SlBRQUTlNt 

- THli  SUBRCUIlNf:  CCMfuTES  CORRfcCTfeU  . 

- RATf-  LHAD  FACTORS*  OcASlRfD  VALLES  Uf  NX  AND  NZ  *Rfc  ROTATED 

- ThRCUGH  THc  RECIIRED  ANGLES  AND  fkANSLATEt  BcTWEEN  BOON  AND  CG 

- At  RiCfSSART* 


VALUES 


NCRNaL 


FLIGHT 


inAP  factor  calculations 
XLVl  • XLVa  ♦ cgt*  >HAC/100*0 

CNXP  ■ (XLVl  /6R)  • ( (DTHETA*  2 ♦ OYAW**  2)  • CCS 
IHA)  - (DBANK*  OYAW-  CZTHET)  • SlN(ALPHA)) 

CNZP  • (XLVl  /GR)  • ((DTHET**  2 ♦ OYAW#*  2)  • 
lALFHA)  ♦ (CBANK*  DYAW-  02THET)  • COS(aLPHA)) 

C^'cCC  JFLG3-1  TO  Set  IF  NECLSSakY  1U  PRINT  SLuLnOaRy  OUTPUT 

IF  (JrLG3  .cO,  I)  UklT|:(6«3t>)  ONXP*  OmZ# 

(*■  FORAATTiH  »1PX,26H<.LTPLT  by  iNXMZ  ON  XP  -jF  lO*5*3X»  SHONiP  ■» 

1 FlU*^) 


JAXlt'2 

IF  ( TNOiX  .cUt  2 ) GC 
>NXW»XNXN*  CCS(ALPHA4 
IIN(ALPHA4  ACCRA) 

IF  ( IMtlFX  .LC,  I ) GU 
'll  XNZW-XNKH*  jiN(ALPHA4 
1 CCS(ALPHA-»  aCCHA) 
XNZWO*  XHZW-  DN7F 
O"  RCTMPN 
FKC 


TO  51 
ACCNA) 

TC  99 
ACCHA) 


XNZM#  S 


« XnZN« 
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